1+1 



Office de la Propri6t6 

Inteliectuelle 

du Canada 

Un organisme 
d'lndustrie Canada 



Canadian 

Intellectual Property 
Office 

An agency of 
Industry Canada 



CA 2271224 C 2003/02/25 

cm™ 2 271 224 

d2) BREVET CANADIEN 
CANADIAN PATENT 

(13) C 



(22) Date de d^pdt/Filing Date: 1999/05/07 

(41) Mise a la disp. pub./Open to Public Insp.: 1999/11/27 

(45) Date de d6livrance/lssue Date: 2003/02/25 

(30) Priorites/Priorities: 1998/05/27 (09/077,337) US; 

1998/07/07 (60/091,887) US; 1998/08/07 (60/095,626) US; 
1998/09/02 (60/098,907) US; 1998/11/17 (09/193,627) US 



(51) Cl.lnt. 6 /lnt.CI. 6 G07F 19/00 

(72) Inventeurs/lnventors: 
RICHARDS, BRUCE G„ US; 
DRUMMOND, JAY PAUL, US; 
BLACKSON, DALE, US; 
CICHON, BOB A., US; 

ESS, JOSEPH C, US; 
MOALES, MARK A., US; 
WEIS, DAVID W., US; 
SMITH, MARK D., US; 
CHURCH, JAMES, US 

(73) Propri6taire/Owner: 
DIEBOLD, INCORPORATED, US 

(74) Agent: DIMOCK STRATTON CLARIZIO LLP 



(54) Titre : GUICHET BANCAIRES AUTOMATISES ET SYSTEME PERMETTANT DE REPONDRE AUX DOCUMENTS 
(54) Title: 1 AUTOMATED BANKING MACHINE AND SYSTEM OPERATIVE TO RESPOND TO HTML DOCUMENTS 



£1 



BACK 
OFFICE 






HTTP 
SERVER 







( INTERNET ^ 
I (WAN) ) 

^-96 



HTTP 
SERVER 



BANK B 



£ 



90 



PROXY 
SERVER 



JAVA 
PROGRAM 



DEVICE 
SERVER 



TOUCH 
SCREEN 



5?r M 




BANK A 



36 



WEB 
BROWSER 



JAVA 
APPLETS 



JAVA 
SCRIPT 



12 



JAVA 
PROGRAM 



DEVICE 
MANAGER 



DEVICE INT. 
SOFTWARE 

E 



64 



£ g g g £ 



CARD 
READER 



KEYBOARD CASH DEPOSITORY PRINTER 
DISPENSER 



(57) Abr6g§/Abstract: 

An automated banking machine (12) is operative to conduct transactions in response to HTML documents and TCP/IP 
messages exchanged with a local computer system (14) through an intranet (16), as well as in response to messages 
exchanged with foreign servers (20, 22, 24, 26, 28, 96) in a wide area network (18). The banking machine includes a computer 
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(57) Abr6g6(suite)/Abstract(continued): 

(34) having an HTML document handling portion (76, 80, 82). The HTML document handling portion is operative to 
communicate through a proxy server (88), with a home HTTP server (90) in the intranet or the foreign servers in the wide area 
network. The computer further includes a device application portion (84) which interfaces with the HTML document handling 
portion and dispatches messages to operate devices (36) in the automated banking machine. The devices include a sheet 
dispenser mechanism (42) which dispenses currency as well as other transaction devices. The device application portion 
communicates with a device interfacing software portion (64) in the banking machine through a device server (92) in the intranet. 
The device server maintains local control over the devices in the banking machine including the sheet dispenser. The banking 
machine operates to read indicia on the user's card corresponding to a system address. The computer is operative to connect 
the banking machine to the home or foreign server corresponding to the system address, which connected server operates the 
banking machine until the completion of transactions by the user. 
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TECHNICAL FIELD 

This invention relates to automated banking machines. Specifically 
this invention relates to an automated banking machine apparatus and system 
that is capable of use in a wide area network, which provides a user with a 
5 familiar interface from their home institution at banking machines operated by 

other institutions, and which provides greater options for machine outputs. 

BACKGROUND ART 

Automated banking machines are well known. A common type of 
automated banking machine used by consumers is an automated teller machine 

1 0 ("ATM"). ATMs enable customers to carry out banking transactions. 

Common banking transactions that may be carried out with ATMs include the 
dispensing of cash, the making of deposits, the transfer of funds between 
accounts, the payment of bills and account balance inquiries. The type of 
banking transactions a customer can carry out are determined by capabilities 

1 5 of the particular banking machine and the programming of the institution 
operating the machine. Other types of automated banking machines may 
allow customers to charge against accounts or to transfer funds. Other types 
of automated banking machines may print or dispense items of value such as 
coupons, tickets, wagering slips, vouchers, checks, food stamps, money 

20 orders, scrip or travelers checks. For purposes of this disclosure an automated 
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banking machine or automated transaction machine shall encompass any 
device which carries out transactions including transfers of value. 

Currently ATMs are operated in proprietary communications networks. 
These networks interconnect ATMs operated by financial institutions and 

5 other entities. The interconnection of the networks often enables a user to use 
a banking machine operated by another institution if the 
foreign institution's banking machine is interconnected with the network that 
includes the user's institution. However when the customer operates the 
foreign institution's machine the customer must operate the machine using the 

1 0 customer interface that has been established by the foreign institution for its 

banking machines. In addition the user is limited to the transaction options 
provided by the foreign institution. 

A customer may encounter difficulties when using a foreign 
institution's machine. Problems may occur because the user is not familiar 

1 5 with the type of machine operated by the foreign institution. Confusion may 
result because the customer does not know which buttons or other mechanisms 
to actuate to accomplish the desired transactions. The transaction flow for a 
customer at a foreign institution machine may be significantly different from 
machines operated by the user's home institution. This may be particularly a 

20 problem when the user is from another country and is not familiar with the 
type of banking machine or the language of the interface provided by the 
foreign institution. Likewise, the documents which are printed by printers in 
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an automated banking machine arc generally limited to a limited group of 
denned formats in a single language. 

A foreign institution may also provide different types of transactions 
than the user is familiar with at their home institution. For example the user's 
5 home institution may enable the transfer of funds between accounts through 
their automated banking machines, to enable the user to maintain funds in 
higher interest bearing accounts until they are needed. If the foreign 

institution does not provide this capability, the user will be unable to do this 
when operating the foreign machine. The inability of a user at a foreign 
1 0 machine to conduct the transactions that they are accustomed to may present 

problems. 

The networks that operate automated teller machines and other types of 
automated banking machines generally operate proprietary networks to which 
access is restricted. This is necessary to prevent fraud or tampering with the 

15 network or user's accounts. Proprietary networks are also generally used for 
the transmission of credit card messages and other financial transaction 
messages. Access to such credit card processing systems is also restricted 
primarily for purposes of maintaining security. 

Communication over wide area networks enables messages to be 

20 communicated between distant locations. The best known wide area network 
is the Internet which can be used to provide communication between 
computers throughout the world. The Internet is not widely used for financial 
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transaction messages because it is not a secure system. Messages intended for 
receipt at a particular computer address may be intercepted at otber addresses 
without detection. Because the messages may be intercepted at locations that 
are distant in the world from the intended recipient, there is potential for fraud 
and corruption. 

Companies are beginning to provide approaches for more secure 
transmission of messages on the Internet. Encryption techniques are also 
being applied to Internet messages. However the openness of the Internet has 
limited its usefulness for purposes of financial messages, particularly financial 
messages associated with the operation of automated banking machines. 

Messages in wide area networks may be communicated using the 
Transmission Control Protocol/Internet protocol ('TCP/IP"). U.S. Patent No. 
5,706,422 shows an example of a system in which financial information stored 
in databases is accessed through a private wide area network using TCP/IP 
messages. The messages transmitted in such networks which use TCP/IP may 
include "documents" (also called "pages"). Such documents are produced in 
Hypertext Markup Language ("HTML") which is a reference to a type of 
programming language used to produce documents with commands or 'tags" 
therein. The tags are codes which define features and/or operations of the 
document such as fonts, layout, imbedded graphics and hypertext links. 
HTML documents are processed or read through use of a computer program 
referred to as a "browser". The tags tell the browser how to process and 
control what is seen on a screen and/or is heard on speakers connected to the 
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computer running Ihe browser when Ihe document is processed. HTML 
documents may be transmitted over a network through the Hypertext Transfer 
Protocol ("HTTP"). Hie term "Hypertext" is a reference to the ability to 
embed links into the text of a document that allow communication to other 
documents which can be accessed in the network. 

Thus there exists a need for an automated banking machine and system 
that can be used in a wide area network such as the Internet while providing a 
high level of security. There further exists a need for an automated banking 
machine and system which provides a user with the familiar interface and 
transaction options of their home institution when operating foreign institution 
machines. There further exists a need for a machine which may provide more 
transaction options and types of promotional and printed materials to users. 

DISCLOSURE OF INVENTION 

It is an object of the present invention to provide an automated banking 
machine at which a user may conduct transactions. 

It is a further object of the present invention to provide an automated 
banking machine that may be operated through connection to a wide area 
network. 

It is a further object of the present invention to provide an automated 
banking machine and system that provides a user with a familiar interface and 
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transaction options of their home institution at machines operated by foreign 
institutions. 

It is a Further object of the present invention to provide an automated 
hanking machine that communicates using HTML documents and TCP/IP 
5 messages. 

It is a further object of the present invention to provide an automated 
banking machine that enables the connection of the banking machine to a 
user's home institution through HTML documents and TCP/IP messages 
generated responsive to indicia on a card input by a user. 
10 It is a further object of the present invention to provide an automated 

banking machine and system that accomplishes transactions over a wide area 
network while maintaining a high level of security. 

It is a further object of the present invention to provide an automated 
banking machine and system that controls connection of the banking machine 
1 5 to foreign addresses through a proxy server. 

It is a further object of the present invention to provide an automated 
banking machine that limits the operation of devices in the machine through a 
local device server. 

It is a further object of the present invention to provide an automated 
20 banking machine and system that is operable through connection to the 
Internet. 
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It is a further object of the present invention to provide an automated 
banking machine that may be used to provide a user with more types of 
messages including messages targeted to particular users. 

It is a further object of the present invention to provide an automated 
banking machine which is capable of providing users with a wider variety of 
printed documents. 

It is a further object of the present invention to provide an automated 
banking machine which provides additional options for identifying authorized 
users. 

It is a further object of the present invention to provide an automated 
banking machine that can be used in connection with existing transaction 
systems while providing enhanced functionality. 

It is a further object of the present invention to provide an automated 
banking machine which provides enhanced diagnostic and service capabilities. 

It is a further object of the present invention to provide an automated 
banking machine which performs transactions at a rapid pace. 

It is a further object of the present invention to provide improved 
systems in which automated banking machines are used. 

It is a further object of the present invention to provide improved 
methods of operation for automated banking machines and systems. 

Further objects of the present invention will be made apparent in the 
following Best Modes for Carrying Out Invention and the appended Claims. 
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The foregoing objects arc accomplished in a preferred embodiment of 
the invention by an automated banking machine that includes an output device 
such as a display screen, and an input device such as a touch screen or a 
keyboard. The banking machine further includes devices such as a dispenser 
5 mechanism for sheets of currency, a printer mechanism, a card reader/writer, a 
depository mechanism and other physical transaction function devices that are 
used by the machine to accomplish banking transactions. 

The banking machine further includes a computer. The computer is in 
operative connection with the output devices and the input devices, as well as 

1 0 with the sheet dispenser mechanism, card reader and other physical transaction 
function devices in the banking machine. The computer includes software 
programs that are executable therein. The software programs include an 
HTML document handling portion. The HTML document handling portion 
operates to send and receive HTML documents and HTTP messages. The 

1 5 HTML document handling portion is preferably in connection with the output 
device to display screens including hypertext link indicators. The HTML 
document handling portion is also preferably in connection with the input 
device which enables user selection and the generation of response messages 
from the computer. The HTML document handling portion preferably 

20 operates in connection with a JAVA software environment and has the 

capability of executing instructions in JAVA script transmitted with HTML 
documents. 
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The software in Ihe computer further preferably includes a device 
application portion. The device application portion includes software that is 
operative to control the sheet dispenser and other devices. In the preferred 
form of the invention the device application portion includes a plurality of 

5 JAVA applets for operating the devices in the machine. 

The computer in the automated banking machine further includes a 
device interfacing software portion. The device interfacing software portion 
operates to receive messages from the device application portion and to cause 
the devices to operate through appropriate hardware interfaces. In one 

1 0 preferred form of the automated banking machine, the HTML document 

handling portion, device application portion and device interfacing software 
portion each reside on the same computer and communicate at different IP 
ports. 

The automated banking machine of the invention in one configuration 
1 5 communicates using TCP/IP messages in an intranet which includes a 

plurality of such machines. The intranet is in turn connected to at least one 
computer which is operated by a home institution. The home institution is the 
entity that operates the banking machines. 

The computer of the home institution preferably includes a home 
20 HTTP server, a proxy server and a device server. The proxy server 

communicates through the intranet with the HTML document handling portion 
of the software in each of the banking machines. The proxy server is also 
connectable to a wide area network, such as the Internet, to which foreign 
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servers are connected. The device server is operative to pass messages 
between the device application portion and the device interfacing software 
portion ofthc banking machines. The device server may include monitor 
software which monitors and selectively limits the use and operation of the 

5 devices in the banking machine. This provides a level of security. 

The automated banking machine and system is operative to place a 
user in connection with the institution where they have their accounts. This 
can be either the home institution that operates the banking machine where the 
user is present, or a foreign institution which is connected to the wide area 

1 0 network. To operate the banking machine a user provides inputs which 

correspond to an address, such as a URL address, through an address input 
device. The HTML document handling portion operates to connect the 
banking machine to the server corresponding to that address. This is 
preferably accomplished by the user having indicia representative of the 

1 5 address on a card that is read by a card reader in the banking machine, or other 

input device which identifies the user or an institution or entity with which the 
user has accounts. 

The HTML document handling portion is responsive to the address on 
the card or other input data to connect through the proxy server to the user's 

20 institution. If the user's home institution address corresponds to the home 

server, the banking machine operates responsive to messages from the home 
server. If however the user's input address corresponds to an address of a 
foreign server, the proxy server is operative to communicate through the wide 
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area network with the foreign server at the customer's home institution. If the 
customer causes the machine to connect a server operated by a foreign 
institution, the HTML documents sent from the foreign institution correspond 
to those normally provided by the foreign institution. As a result the customer 
is familiar with the interface produced by these documents and will be able to 
more readily operate the banking machine. 

The foreign server or home server operate the banking machine by 
sending HTML documents that include instructions for operating the devices 
in the banking machine. The instructions are transmitted from the HTML 
document handling portion to the device application portion of the software, 
which operates the devices in response to the instructions. The instructions 
from the device application portion to the devices in the automated banking 
machine are passed through the device server of the home institution. This 
helps to maintain security. In addition, the proxy server includes screening 
software which limits the foreign servers which may connect to and operate 
the banking machine. This is referred to as a "fire wall." 

Embodiments of the present invention also provide enhanced user 
interfaces and for the printing of a wide variety of documents with the banking 
machine. The invention also enables achieving enhanced functionality while 
utilizing existing transaction networks and automated transaction machines. 



BRIEF DESCRIPTION OF DRAWINGS 
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Figure 1 is a schematic view of a network configuration including the 
automata! banking machine apparatus and system of the present invention. 

Figure 2 is a schematic view ofa preferred embodiment of an 
automated banking machine of the present invention. 
5 Figures 3 through 24 show schematic views of the automated banking 

machine, an intranet connecting the banking machine to a computer system of 
a home bank and a wide area network connecting the computer system of the 
home bank to a foreign bank. 

Figures 3 through 18 schematically represent steps in a transaction 
1 0 carried out at the banking machine with the computer system of the home 
bank. 

Figures 19 through 24 schematically represent steps in a transaction 
carried out at the banking machine with the computer system of the foreign 
bank. 

15 Figure 25 is a schematic view of a network configuration including an 

alternative embodiment of the automated banking machine of the present 
invention. 

Figure 26 is a schematic view of frames in the HTML document 
handling portion of the alternative embodiment of the automated banking 
20 machine shown in Figure 25. 

Figure 27 is a schematic view ofa customer interface of an automated 
banking machine and the function keys and keypad keys included in the 
interface. 
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Figures 28-30 schematically represent exemplary steps in converting 
function key and keypad key inputs to keyboard stream and mouse stream 
inputs. 

Figure 31 schematically represents exemplary steps in printing 
documents with the automated hanking machine. 



BEST MODES FOR CARRYING OUT INVENTION 



Referring now to the drawings and particularly to Figure 1, there is 
shown therein a network configuration schematically indicated 10, which 
includes the automated banking machine apparatus and system of one 
preferred embodiment of the present invention. Network 10 includes a 
plurality of automated banking machines 12 which in the preferred 
embodiment of the invention are ATMs. ATMs 12 are connected to a 
computer system of a home bank schematically indicated 14. Home bank 
computer system 14 is the computer system that is operated by the bank or 
other institution which has primary responsibility for the ATMs 12. Home 
bank computer system 14 is connected to the ATMs 12 through an intranet 16. 
Intranet 1 6 is preferably a local or proprietary network that provides 
communication between the computer system 14 and the banking machines 12 
using messages in the transmission control protocol/internet protocol 
("TCP/IP") format. 
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The messages that are communicated through the intranet 16 are 
preferably TCP/IP messages and hypertext mark up language ("HTML") 
documents. In one preferred embodiment of the invention the HTML 
documents sent through intranet 16 include embedded object oriented 

5 programming instructions, preferably in the JAVA® format which has been 
developed by Sun Microsystems. The messages sent through intranet 16 may 
be sent in an encrypted or unencrypted form depending on the nature of the 
system and the security needs of the home bank. 

It should be understood that embodiments of the invention may 

10 process other forms of documents which include tags or instructions therein. 
For example a form of "extended" HTML has recently been proposed which 
may be used in embodiments of the invention. For purposes of the invention 
all such forms of languages and variants which include documents, which 
documents include instructions therein shall be referred to as HTML 

1 5 documents. Likewise, while JAVA® is used in the described embodiment, 
other programming languages may be used. For example, Active-X™ 
developed by Microsoft Corporation or other languages may be used in other 
embodiments. Further it should be understood that the instructions included in 
documents may be operative to cause a computer to access other documents, 

20 records or files at other addresses to obtain a program to carry out an 
operation. 

Home bank computer system 14 is also connectable as shown to a wide 
area network 18. In some embodiments of the invention the wide area 
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network 1 8 is Ihe Internet. In other embodiments of the invention, other wide 
area networks may he used. The wide area network preferably communicates 
messages in TCP/IP between numerous computer systems connected to the 
wide area network. These foreign computer systems are schematically 
represented by servers 20, 22, 24, 26 and 28. It should be understood that 
servers 20 through 28 may he operated by or connected to other financial 
institutions throughout the world. Servers 20 through 28 preferably operate by 
communicating HTML documents and other HTTP messages. 

Figure 2 shows a schematic view ofthe ATM 12 used in connection 
with one preferred embodiment of the invention. ATM 12 includes a touch 
screen 30. Touch screen 30 includes a display screen which serves as an 
output device for communication with a user of the machine. Touch screen 
30, because it is a touch screen, also serves as an input device for receiving 
input instructions from a user. Touch screen 30 is connected through an 
interface 32 to a computer 34 which is preferably housed within the machine. 
Alternative embodiments of the invention may include other output devices 
such as audio speakers. 

Computer 34 is also in connection with a plurality of transaction 
function devices 36 which are included in ATM 12. Devices 36 include for 
example, a card reader/writer mechanism 38 and a keyboard 40. Devices 36 
further include a sheet dispenser mechanism 42 which is operative to dispense 
sheets, which in some preferred forms of the invention are currency or bank 
notes. Devices 36 also include a depository 44 for accepting deposits into a 
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secure location in Ihe machine. A receipt printer 46 for providing transaction 
receipts to customers is also included among devices 36. A journal printer 48 
is also included among the devices for keeping a hard copy record of 
transaction information. In other embodiments other or additional transaction 
function devices which carry out other transaction functions may be used. 
Other embodiments may include fewer transaction function devices. It should 
be further understood that while the described embodiment of the invention is 
an automated banking machine, the principles of the invention may be 
employed in many types of transaction machines that do not necessarily carry 
out banking transactions. 

Each of the devices is operatively connected to an internal control bus 
50 within the banking machine 12. The control bus 50 outputs the internal 
messages to the particular devices. Each device has an appropriate hardware 
interface which enables the particular device to operate to carry out its 
respective function in response to the messages transmitted to it on control bus 
50. Card reader/writer 38 has a hardware interface schematically shown as 52. 
Hardware interfaces 54, 56, 58, 60 and 62 are respectively operative to 
connect keyboard 40, sheet dispenser mechanism 42, depository mechanism 
44, receipt printer mechanism 46 and journal printer mechanism 48 to the 
control bus 50. 

Computer 34 has several software programs that are executable 
therein. In the preferred embodiment of the invention these software programs 
include a device interfacing software portion generally indicated 64. Device 
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interfacing software portion 64 preferably includes a software device interface 
66 that communicates electronic messages with the control bus 50. The 
device interface software portion 64 also preferably includes a device manager 
68. The device manager is preferably operative to manage the various devices 

5 36 and to control their various states so as to be assured that they properly 

operate in sequence. The device manager is also preferably operable to create 
device objects in the software so as to enable operation of the devices by at 
least one object oriented program 70. Device interfacing software portion 64 
also includes the object oriented program portion 70, which in one preferred 

1 0 embodiment is an application written in the JAVA language. Program 70 
works in conjunction with the device manager to receive object oriented 
JAVA messages which cause the devices to operate, and to transmit device 
operation messages indicative of a manner in which devices are operating 
and/or are receiving input data. 

1 5 The device interfacing software portion 64 in the described 

embodiment operates on computer 34 and communicates through a physical 
TCP/IP connection 72 with the intranet 16. The physical connection may be 
analog dial-up, serial port, ISDN connection or other suitable connection. In 
the configuration of the system as shown, device interfacing software portion 

20 64 communicates at the IP address of computer 34 and at an IP port or socket 
indicated 74 that is different from the other software applications. In other 
embodiments of the invention, device interfacing software portion 64 may 
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operate in a different computer than the other software applications of the 
invention. 

It should further be understood that although in the preferred 
embodiment of the invention the device interfacing portion 64 is software, in 
other embodiments of the invention all or portions of the instruction steps 
executed by software portion 64 may be resident in firmware or in other 
program media in connection with one or more computers, which are 
operative to communicate with devices 36. For purposes of the invention all 
such forms of executable instructions shall be referred to as software. 

Other software also operates in computer 34. This software includes 
HTML document handling software which includes a browser, schematically 
indicated 76. In the preferred embodiment of the invention the HTML 
document handling software includes a browser provided by Netscape®. 
However in other embodiments other HTML document handling and 
communicating software and browser software, such as Hot JAVA® by Sun 
Microsystems or Internet Explorer™ from Microsoft, may be used. Browser 
76 communicates in computer 34 at an IP port indicated by 78. 

Browser 76 is in operative connection with JAVA environment 
software 80 which enables computer 34 to run JAVA language programs. 
JAVA language programs have the advantage that they operate the same on a 
variety of hardware platforms without modification. This "write once\run 
anywhere" capability makes the JAVA environment well-suited for the 
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described embodiment of the invention. However other embodiments may use 
different types of software programs. 

The JAVA environment software 80 enables computer 34 to execute 
instructions in JAVA script, schematically indicated 82. The instructions that 

5 are executed by the computer in JAVA script are preferably embedded JAVA 
script commands that are included in the HTML documents which are 
received through the browser 76. The browser 76 in connection with the 
JAVA environment software 80 which executes instructions in the embedded 
JAVA script 82, serve as an HTML document handling software portion for 

1 0 transmitting and receiving HTML documents and TCP/IP messages through 
the IP port indicated by 78. 

Computer 34 also has executable software therein having a device 
application portion 84. The device application portion 84 contains executable 
instructions related to operation of the devices 36. In the preferred 

1 5 embodiment of the invention, the device application portion consists of a 

plurality of JAVA applets. In the described embodiment the applets are also 
preferably programs operable to control and keep track of the status of the 
devices with which they are associated. Certain applets are also preferably 
operable to configure the browser to communicate messages. Certain applets 

20 manage security and authenticate entities that use the ATM. 

In the described form of the invention, JAVA applets are associated 
with functions such as enabling the card reader mechanism, notifying the 
browser when a user's card data has been entered, operating the receipt printer 
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mechanism, operating the journal printer mechanism, enabling the customer 
keyboard and receiving data input through the keyboard, operating the sheet 
dispenser mechanism, operating the depository, navigating to document 
addresses, timing device functions, verifying digital signatures, handling 

5 encryption of messages, controlling the mix of bills dispensed from multiple 

sheet dispenser mechanisms, calculating foreign exchange, and ending a 
transaction and instructing the browser to return to communication with the 
home server. Of course, in other embodiments, other applets may be used to 
control devices and use data to carry out various desired functions with the 

1 0 machine. The device application portion 84 communicates in the computer 34 
at an IP port indicated 86. 

In the described embodiment of the invention, the device application 
portion 84 of the software does not communicate its messages directly to the 
device interfacing software portion 64. As later explained, this provides 

1 5 heightened security. However it should be understood that embodiments of 
the invention may provide for the device application portion 84 to directly 
communicate device operation messages to the device program 70. This may 
be done either internally using TCP/IP, by delivery of messages in a 
conventional manner through a queue established in the operating system of 

20 the computer that is associated with the software that interfaces with the 
devices, or by direct call to this software. 

From the foregoing discussion it will also be appreciated that certain 
applets in the device application portion 84 may correspond to devices which 
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are not present in all automated teller machines. For example an automated 
teller machine that operates only as a cash dispenser does not include a 
depository mechanism like depository 44. To accommodate the situation 
where a user requests a transaction that is not physically possible with the 
5 ATM 12, the device interfacing software portion 64 may be programmed to 
provide an appropriate response message to indicate that the function is not 
available. 

Alternatively, the device interfacing software portion may include a 
function which checks for the presence or absence of each type of physical 

10 device within the ATM. Information indicative of the devices present in the 
ATM may be included as part of the messages generated by the ATM. For 
example, information indicative of the devices which are operative in the 
ATM may be included as a portion or several parts of the URL addresses to 
which messages are directed by the ATM. In this way, the URL in the server 

1 5 to which the ATM connects may be configured for providing only HTML 

documents which correspond to the types of transactions that the ATM is 
capable of performing. As a result the browser avoids displaying documents 
which include references to transaction types that the machine is not capable 
of performing. Thus for example, a machine may avoid producing a display in 

20 response to a document which includes a reference to a deposit transaction if 
the machine does not include a depository. 

Alternatively the machine may include in memory, data representative 
of the functional devices included in the machine. This may include for 
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example data representative ofa plurality of devices in the machine and the 
configurations of such devices, or alternatively, a designator such as a machine 
number sufficient to identify the capabilities of the machine. The device data 
indicative of the functional devices in the machine is communicated to a 
server and the server is operative to deliver the appropriate HTML documents 
for the devices present in the machine. This may be done based on the data 
corresponding to the device data from the machine or may be resolved from a 
memory which holds data representative of the functional devices in a 
machine associated with a particular designator. Documents selectively 
delivered by the server to the browser of the machine will include the 
appropriate references to the functional devices present in the machine. These 
documents may be static documents or may be generated at run time from sub- 
documents or otherwise, to provide the appropriate outputs and instructions to 
the output devices of the transaction machine. 

Figure 3 shows the ATM 12 in communication through the intranet 16 
with the home bank computer system 14. Computer system 14 includes a 
proxy server 88. System 14 farther includes a home HTTP server 90. 
Computer system 1 4 further includes a device server 92. The proxy server, 
home HTTP server and device server may be included in a single computer as 
shown, or in other embodiments may be separate computers. Additional 
servers may be operative in other embodiments. 

The home HTTP server 90 is preferably in communication with a data 
store and is in electronic communication with a back office computer system, 
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schematically indicated 94. Back office computer system 94 is operative to 
keep track of debiting or crediting customers 1 accounts when they conduct 
transactions at the automated hanking machines. In addition back office 94 is 
also preferably operative to track transactions for purposes of accomplishing 

5 settlements with other institutions who are participants in the system and 
whose customers conduct transactions at the ATMs 12. 

As later explained, proxy server 88 is also operative in the described 
embodiment to communicate through the wide area network 1 8 with foreign 
servers such as foreign server 96. Foreign server 96 is an example of a server 

1 0 operated by an institution or entity other than the institution which operates 
computer system 14. It should be understood that while foreign server 96 is 
indicated as operated by a "foreign" institution, this is not necessarily 
indicative that the institution is located in another country from the institution 
that operates computer system 14. However, it is possible that foreign server 

1 5 96 could be located in such a foreign country, including a country in which the 

language spoken is different from that generally used in the country where 
ATM 12 is located. 

The conduct of transactions using the ATM 12 is now explained with 
reference to Figures 3-24. It should be understood that the following 

20 described transaction flows are merely examples of the operation of the 

apparatus and system, and the apparatus and system may be configured and 
operated in numerous ways to carry out transactions. 
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At Ihe start of an exemplary transaction, as schematically represented 
in Figure 3, the browser 76 communicates through the intranet 16 with the 
proxy server 88. The communication is established preferably in a manner so 
that HTML documents intended to attract customers to the ATM 12 are 

5 displayed on Ihe touch screen 30. This is referred to as the "attract mode." 

These HTML documents which are processed in Ihe browser to produce the 
outputs in the form ofscreens on the touch screen 30 (and/or outputs through 
other output devices included in the machine) may originate from home HTTP 
server 90 which is operative to deliver the HTML documents to the proxy 

1 0 server. The home HTTP server sends the messages addressed to the IP port 
associated with browser 76, so as to cause their display at the proper ATM 
machine. It should be understood that while in this example, home server 90 
is described as communicating with the ATMs through the proxy server 88, 
the server 90 may in other systems encompassed by the invention 

1 5 communicate directly with the ATMs. 

A fundamental advantage of the system is that home HTTP server 90 
may deliver documents selectively to the ATMs 12 connected to the intranet 
16. These documents may include messages or material tailored to the 
particular location in which an ATM 12 is located. Examples of particularly 

20 tailored screens may include bilingual messages in certain neighborhoods or 
information concerning currency exchange at various ports of entry. The 
material or messages could include advertising for various products or services 
or other material targeted to particular machine locations. The JAVA applets 
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and JAVA script are loaded from a central location providing selective 
software distribution in the ATMs which may also be used to tailor (he ATM 
to its environment by causing it to access documents which include material 
intended to be useful in that location, and which is not provided in documents 
delivered to at least some other machines in the system. 

Systems of the present invention may be configured to have selected 
machines access HTML documents at different addresses, so that the 
particular documents accessed include the material targeted to users of the 
particular machine. Alternatively, a machine may communicate machine data 
indicative of its identity and/or location to a server. From the machine data, 
and data stored in a data store in connection with the server, the server 
operates to deliver the documents including the targeted material. This may 
be accomplished by assembling subdocuments, or otherwise, to generate the 
documents that will be delivered to the browser of the particular machine. In 
addition it should be understood that while in the embodiment shown the 
HTML documents are accessed through a server of an institution associated 
with the machine, the documents used for the attract mode may be accessed 
from other servers operated by other entities. 

The touch screen 30 in this exemplary transaction sequence displays a 
screen which includes an icon which indicates in one or more languages that to 
commence a transaction a user should touch the screen. If a user touches the 
screen in the area of the icon an input signal is generated. The input signal or 
HTTP message is transmitted through the browser 76 to the home address of 
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the home HTTP server 90 to which the ATM 12 is currently in 
communication. The message generated hack to the home HTTP server is 
represented hy the arrows directed from the browser 76 to the intranet 16, 
from the intranet 16 to the proxy server 88, and from the proxy server to the 
HTTP server 90 in Figure 3. 

In response to the home HTTP server 90 receiving the message 
indicating that a customer has touched the icon on the screen, the home server 
is operative responsive to the address accessed to send a message through the 
proxy server 88 (or in other embodiments directly) to the browser 76. This 
message preferably includes an HTML document which when processed 
through the browser produces a screen instructing the customer to insert their 
card into the card reader mechanism 38. The HTML document flow which is 
represented graphically in Figure 4, preferably also includes embedded JAVA 
script or other instructions which operate in the JAVA environment to 
communicate a message to the JAVA applet responsible for enabling the card 
reader in the device application portion 84. In one preferred embodiment the 
instructions provide a pointer or tag to the applet which executes responsive to 
receipt of the document instructions. Of course in other embodiments other 
software and approaches may be used. 

As shown in Figure 5, in response to the embedded JAVA script 
activating the JAVA applet associated with the enable card reader function, 
the JAVA applet in the device application portion 84 communicates with the 
device server 92. The device server 92 includes a device server program 98 
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which in (he preferred embodiment is a JAVA program that enables 
communication with the JAVA applets and the device server application 100. 
The device server 92 further preferably includes a monitor software 
application 102 which is operative to monitor device operation instructions. 
5 The monitor software minimizes the risk of fraud or abuse in a manner later 

explained. 

Returning to the sample transaction, in response to receiving the enable 
card reader message from the device application portion 84, the device server 
92 is operative to generate a message through the intranet 1 6 to the device 

1 0 interfacing software portion 64 of the ATM 12. This message which 

comprises an HTTP record including instructions for operating the card reader, 
is directed to the IP port indicated 74 which is where the device interfacing 
software portion 64 communicates. In response to receiving this message, the 
software portion 64 is operative to send a message or messages on the control 

1 5 bus 50 which enables card reader mechanism 34. 

Continuing with the transaction as shown in Figure 6, the input of the 
card by the customer to the card reader 34 is operative to cause the card data to 
be read and the device interfacing program portion 64 to send a message to the 
device server 92 indicating the card data has been read. This message is 

20 transmitted by the device server through the intranet 1 6 to the device 

application portion 84. The device application portion then sends a message 
to the device server requesting the card data. The device server 92 transmits a 
message with instructions to deliver the card data from the device interfacing 
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'software portion 64 which responds with a message sending Ihe card dala 
through Ihc intranet to the device server. The device server, if there is no hasis 
for stopping the transaction, transmits an HTTP record including card dala 
hack through the intranet 16 to the device application portion 84. 

In one preferred embodiment of the invention, the card input by a user 
or customer includes indicia which corresponds to an address associated with 
the user in the network. In such an embodiment the indicia corresponds to a 
uniform resource locator ("URL") address which provides information on the 
computer where the user information resides, as well as a directory or 
subdirectory which includes the user information and the name of the 
document or resource that includes the user information. The URL address 
may be encoded on a customer's card. The address may be encoded on track 3 
of a magnetic stripe, in other locations within the magnetic stripe data or 
through encoding other readable indicia on the card. Alternatively, if the 
customer's card is a "smart" card which includes semiconductor storage 
thereon, the URL address associated with the customer may be included as 
part of the stored data on the integrated circuit chip on the customer's card. 
Alternatively, a URL could be derived from other data on the card by 
accessing a data base in which address data is correlated with other data read 
from the card. The data necessary to derive the address for accessing 
documents associated with a customer could also be derived from inputs to 
input devices other than or in addition to card data, including for example 
biometric data which is input by a customer through a biometric reading 
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device. Such biomctric data may include for example, data corresponding to 
one or more fingerprints, data from the user's appearance or combinations 
thereof. 

For example and without limitation, data input by a customer such as 

5 through a card input to a card reader may correspond to an address for 

accessing an HTTP record, which may he a file or document which includes 
information which can be used for verifying the identity of a user. This record 
could include data corresponding to a PIN number. The information may 
include biometric data corresponding to the authorized user of the card. The 

1 0 browser may access the record and use the contents of the record such as data 

and/or instructions to verify that the indicia corresponding to biometric data in 
the record corresponds to the biometric data of the user entering the card. 
Alternatively, input data representative of appearance, voice, other features (or 
combinations thereof) or other input data, may be used to generate one or 

1 5 more addresses which correspond to a user, and the content of the record at the 

accessed address used to verify that the user at the machine corresponds to the 
user associated with the record. Numerous approaches within the scope of the 
invention may be used. The information in the record corresponding to a user 
may likewise be used to authorize certain functional devices on the machine to 

20 operate for the user while other devices may not. For example, a user who is 
overdrawn may have information in the record accessed that prevents them 
from actuating the cash dispenser, while users who are not overdrawn may 
include information which enables such operation. Alternatively, the absence 
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of information in a corresponding record may enable operation, while the 
inclusion of information selectively limits the operation of devices. 

Returning to the exemplary transaction, the delivery of the card data 
from a successfully read card is delivered responsive to the programming of 
5 the device application portion 84 to a JAVA applet associated with notifying 

that the card data has been entered. In response, the JAVA applet operates to 
generate JAVA script which configures the browser with the URL address 
corresponding to the data read from the card. The JAVA applet is also 
preferably operative to open a record schematically indicated 104 concerning 

10 the transaction, which includes the user's URL address, the time and other card 
data. This record in a preferred embodiment may be stored in memory as data 
in an object in software. The object is preferably used to accumulate data as 
the transaction proceeds. The data stored in the transaction data object 
preferably includes data input through input devices by the user as well as data 

15 representative of operations carried out by transaction function devices. 

The record or transaction data object provides persistence through what 
may be several different transaction steps executed by the customer. The 
ability to use and share the data in a number of different operations avoids the 
need to derive it or obtain it from a customer more than once in the course of a 

20 user session involving a number of transaction steps. The use of a transaction 
data object enables applets to run largely independently, obtaining needed data 
from the transaction object. The approach also enables the record or data 
object to be used to produce an appropriate record at the end of the transaction 
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session. This record may be stored, collected into a batch or delivered lo 
selected addresses in a local or wide area network. 

As schematically shown in Figure 7, in response lo the browser 76 
receiving the URL address data, the browser is operative to transmit a message 
through the intranet 1 6 lo the proxy server 88. For purposes of this example, 
the URL address associated with the card data is that of a customer associated 
with the home bank which operates system 14. As a result, the customer's 
URL address will cause the message to be directed from the proxy server 88 to 
the home HTTP server 90 and to access the corresponding document at the 
address therein. Alternatively, in other systems the connection may be made 
directly with server 90 without the intervening proxy server 88. As previously 
discussed, the URL address may also include data representative of the 
devices which are operative in the ATM. 

In response to receiving the message, home HTTP server 90 finds the 
data corresponding to the customer's URL address data in its associated 
memory and delivers to the browser at its IP port with an HTML document. 
This HTML document may include a screen acknowledging the particular 
customer by name as well as with the name of the banking institution or other 
entity which operates the home bank computer system 14. 

In addition, the HTML document preferably includes embedded JAVA 
script which has a digital signature or a means to obtain a digital signature 
associated with the home HTTP server 90. The script instruction included in 
the document in certain embodiments causes the device application portion to 
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access an I I TU* address on a server, which in the described embodiment is 
server 90. The I NTP address corresponds !o an I ITTP record which includes 
al leasl one instruction and preferably includes a program such as a JAVA 
applet or Aclive-X Hie. The instruction is used to operate the appropriate 
5 transaction function device. The HTTP record preferably includes data 

representative of a signature, such as a digital signature. This digital signature 
is received responsive to the JAVA script 82 and processed in the device 
application portion 84. A JAVA applet processes the digital signature to 
authenticate it and if it is an acceptable signature authorizes operation of the 
10 banking machine. In certain embodiments the applet may compare the 

signature to signature data stored in memory for a predetermined relationship, 
such as a match. 

After the applet verifies that HTTP server 90 or other accessed HTTP 
record has sent a proper digital signature, the transaction will be allowed to 

1 3 continue. If for some reason a proper digital signature has not been sent, the 

JAVA applet will stop the transaction and return banking machine 12 back to 
the condition prior to the start of the transaction by connecting the ATM to the 
address associated with the attract mode in home server 90. The use of signed 
instructions may be used to assure that the various transaction function devices 

20 are only operated in response to appropriate messages. The use of signed 

instructions may be particularly appropriate for instructions that run the sheet 
dispenser or otherwise provide value to the user of the machine. 
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In the example il will be assumed that Ihc digital signature reeeivcil is 
a proper signature, in which ease a message is returned from the browser 76 lo 
home server <J0 indicating thai the transaction may proceed. As shown in 
Figure 8, in this exemplary transaction the HTTP home server 90 then 
operates to send an HTML document lo the browser 76 which includes 
instructions which when processed produce a page or screen which instructs 
the customer to enter their personal identification number or PIN. This I ITML 
document preferably includes embedded JAVA instructions which operate to 
cause the device application portion 84 enable the keyboard 40 of the ATM so 
the machine may receive the PIN number. Such a message is schematically 
shown in Figure 8 with the JAVA script 82 signaling the JAVA applet 
responsible for the keyboard that it has been requested to enable the keyboard. 
In response the JAVA applet in the device application portion 84 sends a 
message through the intranet 1 6 to the device server 92. The device server 92 
sends a message back through the intranet to the device interfacing software 
portion 64 in the ATM. The instructions in this message causes the device 
software to enable keyboard 40. The JAVA applet responsible for enabling 
the keyboard is also preferably operative to update the transaction record 104 
to indicate that the PIN was requested. 

As shown in Figure 9, the PIN entered through the keyboard 40 is 
transmitted in a message from the device interfacing software portion 64 to the 
device server 92. The device server 92 returns a message to the responsible 
JAVA applet in the device application portion. The JAVA applet then 
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operates to send a message back through the HTML document handling 
portion and the browser 7d to the 1 ITTP address of home server 90. This 
message includes data representative of the PIN input by the customer. In 
some embodiments it is not desirable to display the customer's PIN on the 
screen. In such embodiments the keyboard applet may be operative to display 
a default character on the screen such as a symbol or other symbol in lieu 
of the PIN digits. Further as later discussed it may be desirable to avoid 
transmission of PIN or other data through the browser, in which case PIN data 
may be handled as a separate HTTP message or in other manner to reduce the 
risk of disclosure. 

The software operating in connection with HTTP server 90 is then 
operative to either verify the PIN itself or to verify the customer's PIN number 
and account number by sending it to the back office 94 and waiting for a 
response. Alternatively, customer PIN verification may be carried out in the 
ATM through an appropriate applet. This can be done in situations where data 
on a customer's card, such as an account number, can be correlated to the 
customer's PIN number through an algorithm. The embedded JAVA script in 
the HTML messages may include or point to an address to obtain the data 
and/or instructions which the applet uses to perform this verification function, 
including certain encryption key data. This may include user information in 
the HTML document or other record data that was accessed in response to the 
user's card data. As shown schematically in Figure 9, the transaction data 
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object 104 is also appropriately updated by the applet to indicate the entry of 
the customer's PIN. 

In alternative embodiments the machine may include a biometric 
reader device or other input device to accept data from a user. The user may 
input data through such a device which may be used in lieu of, or in addition 
to, PIN data to verify that the user is an authorized user. This may be done for 
example by comparing the user data input to information corresponding to the 
authorized user of the card included in a record or a document which has an 
HTTP address and is accessed by a browser or by an HTTP client application 
through an HTTP server in response to card data. Alternatively input data 
may be used to generate addresses for documents or records which are 
accessed by the browser or client, and which records or documents contain 
information that is used to verify the user's identity. For example, data 
concerning users may be stored in a data store in connection with an HTTP 
server, which delivers data from a record responsive to the user data, which is 
used to verify the user's identity. 

It should be noted that the page or screen which requests the customer 
to enter their PIN is shown generated from the home HTTP server 90. This is 
preferably a screen that is associated with the particular customer's URL 
address. This will be the interface of the customer's home bank and will be 
familiar to the customer. Alternatively, the customer address may access what 
may be essentially the customer's personal "home page" with the institution 



CA 02271224 1999-05-07 



36 

that operates computer system 14. As such, it is not only something the user is 
familiar with, but is ideally tailored to the user's particular transaction needs. 

Alternatively, the document(s) or record(s) which contain the customer 
data may be used to generate the addresses for other documents. The 
information may also be used to generate a document for the particular 
customer in the particular circumstances. This approach may be useful to 
reduce the effort associated with developing in advance a personal visual page 
or document for each customer. 

Approaches for accomplishing this may involve including various 
types or categories of user information in the document(s) or record(s) that 
pertain to a particular customer. This may include information such as gender, 
related persons, account types, permitted transactions, customer preferences, 
customer interests, account balances, previous offers declined or accepted and 
other information. This customer information can be used by an appropriate 
applet among applets 86 to address and/or develop an appropriate document 
for the browser to access based on the customer "profile". In addition, the 
profile applet may take into consideration the transaction devices present in 
the particular machine, information on which is stored in a data store in the 
machine or elsewhere in the system, as well as other factors such as the day of 
the week and time of day based on a system clock. In this way the machine 
determines the appropriate document to access or generate for the particular 
customer under the particular circumstances. 
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The logic used in the profile applet may act to cause documents to be 
built or accessed for the customer which includes transaction options based on 
the customer information, information about the terminal arid other factors. 
The profile applet may operate to offer transaction options or information 
selectively based on the customer information. For example, the operator of 
the machine may offer incentives, premiums, additional transaction options or 
advertising information selectively to customers. Certain types of customers 
of the institution operating the machine may receive screen outputs with 
options that encourage them to do more business or different types of business 
with the institution. Likewise, customers that are identified as customers of 
foreign institutions may be provided with incentives to do business with the 
institution operating the machine. 

The profile applet may operate to cause the computer to access other 
documents in other servers, such as stock market data, and selectively provide 
it to customers. It should be understood that the profile applet may operate to 
determine an address or generate documents to produce initial display screens 
of a transaction sequence. The profile applet may also operate to provide 
information or access or produce documents to generate visual outputs to the 
customer at other points in a transaction or between transactions. This may 
further be used in systems in which the operator of the machine is able to sell 
paid advertising to third parties and then access the HTTP records such as 
HTML files for those third parties' products or services. Such accessing may 
be done based on a periodic or other basis, but may be done effectively by 
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selecting the HTTP record to access in response to the profile of the particular 
customer. 

The continuation of the transaction flow for this exemplary transaction 
by a customer of the institution that operates computer network 14, is 
5 schematically shown in Figure 10. The home HTTP server 90 is operative in 
response to the customer inputting the correct PIN to send HTML documents 
to the HTML document handling portion of the software in the computer 
which operates the ATM. These messages may include information used to 
generate screens which prompt the customer to select a transaction. For 

10 purposes of this example, it will be assumed that the customer inputs at the 
touch screen 30 a selection which corresponds to the dispense of cash, which 
is a common transaction at an automated banking machine. 

The selection of the customer through the input device of the touch 
screen is communicated back through the HTML document handling portion 

1 5 which communicates an HTTP message to the home HTTP server 90. Server 
90 then responds by sending another HTML document to the banking machine 
which prompts the customer to select an amount. Again the customer may 
input a selection on the touch screen which indicates the amount of cash 
requested by the customer. This HTTP message passes through the HTML 

20 document handling portion and the browser 76 to the home server 90. 

In response to the receipt of amount data from the customer, the home 
server 90 is preferably operative to communicate electronically with the back 
office 94 to verify that the customer has the amount requested in their account. 
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This is preferably accomplished through a Common Gateway Interface (CGI) 
1 06 which is in operative connection with the home server 90. For purposes 
of this transaction it will be assumed that the back office 94 indicates that the 
money is available in the customer's account and sends a message through the 
5 CGI 1 06 to the home server 90 indicating that it may proceed. 

As schematically represented in Figure 1 1, the home server 90 then 
operates to send a document back to the HTML document handling portion in 
the ATM software. This message preferably will cause information to be 
displayed on the screen which advises the customer that the transaction is 
10 being processed. In addition the HTML document returned preferably 

includes JAVA script which include embedded instructions which are 
executed and communicated to a JAVA applet associated with the operation of 
the sheet dispensing mechanism 42. 

The document returned from the home server 90 may include 
1 5 advertising or other information instead of or in addition to the customer 

message. The document returned may also include an instruction which 
causes the machine to access or generate another document. These 
instructions may invoke methods in the profile applet which depend on the 
properties associated with the customer, the machine, the current time and/or 
20 other circumstances. This enables accessing documents that provide 

promotional messages such as advertising or other information to the customer 
while the customer is waiting for the machine to operate. It should be 
understood that these documents may be accessed anywhere, including from 
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the Internet. This makes it possible to selectively present a wide range of 
materials to customers. It also enables operators of ATMs and other 
transaction machines to present advertising to customers, on a broad basis, or 
targeted to categories of customers or even targeted to individual customers on 
5 a segment of one basis. This could be advertising of the machine operator 

such as a bank, or advertising pertaining to virtually any type of goods or 
services. The advertising may also be selectively presented based on the 
particular transaction device being operated, the amount of funds involved or 
other parameters. The HTML documents also enable the presentation of video 
1 0 and sound to the customer which may enhance the effectiveness of 
promotions. 

The message to the JAVA applet in the device application portion 84 
of the software to initiate operation of the sheet dispenser results in generation 
of a message to the device server 92, The message to the device server 92 to 

15 dispense cash is preferably analyzed by the monitor software 102 to check to 

see if the message is appropriate. For example the monitor software 102 is 
preferably operative to assure that the amount of cash being requested does not 
exceed a preset amount. It can also optionally check to verify that the amount 
provided to this customer within a prior period has not exceeded an amount. 

20 This may be done by the device server sending a message to the back office 
which includes the card data it has previously received from this customer. 
This message may pass through server 90 and its associated CGI, or other 
connection. Assuming that the dispense instruction is not prevented by a 
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message from the back office or the monitor software, the device server 92 is 
operative to send a dispense message to the device interfacing software portion 
64 in the ATM. The software portion 64 is thereafter operative responsive to 
the message to operate the sheet dispensing mechanism 42 to dispense the 
5 amount of cash requested by the customer. 

The monitor software 102 preferably performs additional functions in 
the device server. For example, government regulations or good business 
practice may require limiting the size and amounts of deposits which may be 
made into an ATM. This may be advisable to prevent "money laundering" or 

1 0 other suspicious activities. The monitor software preferably operates to limit 
the amount of any single deposit to below a set limit. It further operates by 
communicating with the home bank back office system 94 to prevent a series 
of deposits within a preset time .from exceeding a certain limit. The monitor 
software may also work in connection with the proxy server to limit certain 

1 5 transactions that may be carried on at the banking machine responsive to 

instructions from foreign servers as later discussed. 

It should be noted that in a preferred embodiment of the invention the 
JAVA applet which is operative to send the message which causes cash to be 
dispensed, works in connection with another applet which controls the mix of 

20 bills dispensed to a customer. Many automated teller machines have the 

ability to dispense two or more denominations of currency bills. It is desirable 
to control the mix of bills dispensed to a customer to suit that which is 
available in the machine and to avoid running out of one denomination of bills 
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before the other. The bill mix applet is preferably operable to control the bill 
mix in accordance with the desires of the institution operating the ATM 
machine as well as is in accordance with the ATM machine's capabilities. 
Alternatively, a JAVA applet for controlling bill mix may reside in device 
5 program 70 in device interfacing software portion 64. 

As will be appreciated by those skilled in the art, the particular JAVA 
applets and/or configuration data in the machine may be selectively loaded 
from the home server 90 at machine start up or at other times. Because the 
applets and configuration data may be selectively delivered to particular 

10 machines, the machines may be tailored specifically to the particular ATMs 
currency dispensing and other capabilities. For example, the ATM may be 
configured so that certain applets or groups of applets must be present to 
enable the machine to operate. One approach to loading such data or 
programs is to provide address values in the terminal software to indicate 

1 5 where the needed instructions to acquire the applets or data may be obtained. 
If the applets or groups of applets are not already present in memory of the 
ATM terminal at start up, the software is operative to access the system 
addresses for the documents which contain the required records or instructions 
which will cause the machine to load the required records. The browser may 

20 be used to access the addresses and the software loads data corresponding to 
the instructions from the accessed documents into a memory in the ATM 
terminal so that the terminal has the required applets and data. Such document 
addresses may be accessible through the home server 90. Alternatively the 
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addresses may be on a separate development server connected to the intranet 
16. In this way each transaction machine is able to load the applets and data 
which include the operative code it needs to operate the transaction devices in 
the machine. Alternatively, the documents may be provided through a 
5 development server or other server that is accessible to the machine through a 

wide area network. The documents may be provided on the development 
server to provide the machine with instructions on how to acquire the 
operating code to carry out a wide variety of functions. The instructions may 
direct the machine to acquire the necessary data and code from addresses 

1 0 accessible through HTTP servers by an HTTP client in the machine. The data 
and code can be acquired responsive to instructions in one or several 
documents. The machine may also require that the applets loaded in this 
manner be signed applets including digital signatures or other authenticating 
features to achieve operation of certain devices in the machines. 

1 5 Alternatively, embodiments of the invention may acquire the necessary 

applets and data from a remote data store. The data store preferably includes 
the data and/or programs that enable the machine to operate as desired or have 
instructions on where the machine may acquire the necessary instructions and 
data for operation. The data may be accessible from a data base server. The 

20 transaction machine addresses a query to the database server. The query 

includes or is accompanied by indicia from the machine which identifies the 
machine. This may be the particular machine such as a machine number, 
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and/or may include indicia representative of the type or functional device 
capabilities of the machine. 

The data store preferably includes records which have the data or 
programs that are to be transmitted to the machine. In response to the query to 
5 the server, the server retrieves records from the data store and responsive 
thereto delivers one or more messages to the HTTP client in the transaction 
machine. This message(s) includes the configuration data or applets to enable 
the machine to operate in the manner desired or may include instructions 
which indicate how the machine is to acquire such programs from servers 

1 0 connected in the system. 

In the example shown the configuration server and data store may 
operate on the same computer as home bank server 90. In other embodiments 
the database server may reside elsewhere in the networks to which the 
machine is connected. 

1 5 An advantage of the machines and systems which employ such 

features is the flexibility to change the operation and customer interface of the 
machine to respond to changing conditions. This may include a change in a 
transaction function device. Conditions may change so that certain 
transactions are limited or are not available. For example, a machine may 

20 normally accept deposits but its depository is full. In that situation the 

machine may change the documents it accesses to present messages to users 
through its output devices so that the deposit option is no longer offered. This 
can be accomplished by the applets and data loaded into the machine initially, 
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which provide for instructions when such event is sensed. Alternatively, the 
machine programming may be modified by loading new applets and/or data 
from an HTTP server responsive lo its then current status. This may be done 
responsive to a query to a database server which includes or is accompanied 

5 by data representative of the changed conditions or capabilities of the 

machine. In response the server delivers the applet(s), data and/or instructions 
which will operate the machine in the modified mode. 

This approach eliminates the situation with conventional transaction 
machines where the static interface presentation on output devices offers a 

10 transaction option to a customer. Sometimes, after the customer has made the 
selection an indication is given that the selected transactions option is not 
available. The approach described herein may be used with numerous 
transaction options and variations of transactions. The transaction options can 
be readily changed from the database server on a machine by machine basis or 

1 5 even a customer by customer basis as previously discussed, based on the 
desires of the entity operating the transaction machine. 

The discussion of the exemplary transaction will now be continued. In 
response to the cash dispenser 42 dispensing the requested amount of cash, 
device interfacing software program 64 preferably operates to send a dispense 

20 operation message confirming the dispense back to the JAVA applet 
responsible for the dispense in the device application program 84. As 
represented in Figure 12, the particular applet is operative to update the 
transaction record 1 04 to indicate the dispense of currency to the customer in 
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the particular amount. The embedded JAVA script instructions which were 
operative to cause the dispense of currency to the customer, also preferably 
include instructions to send a confirming message back to the home server 90 
that the dispense is complete. The receipt of the dispense operation message 

5 indicating the cash was dispensed causes the JAVA applet to configure the 

HTML document handling portion to send a device response message back to 
the home server. The home server then is preferably operated in accordance 
with its programming to indicate to the back office 94 that the customer 
received the amount of funds dispensed. This amount is deducted from the 

10 customer's account in the records maintained by the back office system. 

Generally during a transaction it is common to ask the customer if they 
wish to have a receipt for the transaction. This may be done at various times 
during the transaction flow. In the present example, after the cash has been 
dispensed the customer operating the machine is sent such a message as 

15 reflected in Figure 13. The home server 90 is operative to send an HTML 
document which includes a screen asking the customer if they would like a 
receipt. This message is displayed as part of a page on the touch screen 30 
responsive to receipt of the message through the browser 76. Alternatively the 
document may be generated by the machine. In response to the customer 

20 indicating that they do or do not want a receipt, a message is returned to the 
home server. Again it should be understood that the screens displayed to the 
customer are preferably those that the customer is accustomed to from his or 
her home institution, and may be a part of his or her unique home page. 
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Assuming that ihe customer wishes to receive a transaction receipt, the 
home server 90 operates as shown in Figure 14 to send a document back to the 
ATM with embedded JAVA script indicating that a transaction receipt is to be 
printed. These instructions in JAVA script are communicated to the device 

5 application portion 84 which sends a TCP/IP message through Ihe intranet to 
the device server 92. The device server 92 in turn communicates a message 
with instructions to the device interfacing software portion 64 in the ATM. In 
response to receiving the message, software portion 64 is operative to cause 
the printer 46 to print the customer's transaction receipt. The JAVA applet 

1 0 responsible for enabling the printer is also preferably operative to update the 
transaction data object or record 104. As later discussed, the applet which 
controls the printing of the receipt may obtain the data used in printing the 
receipt from the transaction data object. 

It should be understood that even if the customer does not wish to have 

1 5 a receipt it is desirable to print a record of the transaction in hard copy through 
the journal printer 48. This may be accomplished in response to imbedded 
instructions which are part of the same document from the home server 90 
which causes the transaction receipt for the customer to be printed, or may be 
part of a separate document which indicates that the customer has declined the 

20 option to receive a transaction receipt. Alternatively, the journal printer may 
be actuated responsive to other applets such as the applet which causes the 
dispense of cash, or in another manner chosen by the operator of the ATM. As 
will be appreciated from the foregoing description the operation of the 
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preferred embodiment of the ATM is inherently flexible and programmable to 
meet the needs of the system operator. 

As shown in Figure 15 upon completion of the printing of the 
transaction receipt, the software portion 64 is preferably operative to send a 
device operation message lo the device server 92 which is indicative that the 
requested device function was carried out successfully. The device server 92 
is operative lo send a corresponding device operation message to the device 
application portion 84, and in the preferred embodiment to the particular 
JAVA applet responsible for the printing of the receipt. The JAVA applet in 
turn configures the HTML document handling portion to generate a message 
back to the home server in the form of a device response message to indicate 
that the receipt was printed for the customer. 

Having received cash and a receipt, the customer is then prompted by a 
display screen generated from an HTML document from the home server 90, 
to indicate whether they wish to conduct another transaction. The visual page 
or screen prompting the customer in this regard is displayed on the touch 
screen 30. For purposes of this example it will be assumed that the customer 
does not want another transaction and a message to that effect is returned 
through the HTML document handling portion back to the home server 90. 

As shown schematically in Figure 17 in response to receiving a 
message that the customer is done, the home server 90 is operative to send a 
"go home" message to the ATM. This message preferably includes an HTML 
document which produces a screen display thanking the customer. This 



CA 02271224 1999-05-07 



49 

message also preferably includes embedded JAVA script which calls the 
JAVA applet which eventually returns the HTML document handling portion 
of the ATM hack into connection with the URL address on the home server 90 
or other address which provides the documents that arc used to output the 
messages for the so called "attract mode". It should be remembered that the 
script in some embodiments may operate to cause a message to be sent from 
the document handling portion to an address on the home server which causes 
a corresponding HTTP record including the instructions comprising the 
desired applet to load. 

As schematically indicated in Figure 18, the "go home" command 
applet is operative to configure the browser 76. After the HTML document 
handling portion is configured by the JAVA applet to return home, the JAVA 
applet may be configured to deliver to home server 90 information from the 
transaction record 104 concerning the transaction that was just completed. 
Because the exemplary transaction was with a customer of the institution that 
operates the computer system 14, all the data concerning that transaction 
should already be recorded in the back office 94. However it will be 
appreciated that this will not be the case if the transaction was conducted in 
response to messages from a server operated by a different institution. Thus, 
all or a portion of the information from the transaction record 104 may be 
delivered in response to a "go home" command to the home server 90 and 
through the CGI to the back office system 94 where it can be identified as 
duplicate information and discarded. This may be done using remote method 
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invocation (RM1) to pass or deliver the object to server 90 and then 
transmitting the data through messages from the server to the back office or 
through messages or other techniques. 

Of course in other embodiments transaction information may be stored 
5 in a database for extended periods rather than being relumed after each 

transaction. Alternatively the ATM 12 oflhe present invention may include 
applets which are operable to deliver transaction record information to 
addresses other than that oflhe home server, if that is desired by the operator 
of system 14. 

1 o The operation of the computer system when a "foreign" user uses the 

ATM 12 is graphically represented with regard to Figures 19 through 24. A 
transaction with a foreign user who is not a customer of the institution that 
operates ATM 12 and computer system 14, will be operated under the control 
of the home server 90 and will proceed in the manner of the prior example 

1 5 through the point where the customer inputs their card. The customer inputs a 
card having indicia corresponding to a URL address that does not correspond 
to the home server 90. The HTML document handling portion is operative to 
configure a message addressed to access a URL address that corresponds to 
the indicia on the customer's card or other address responsive to such indicia. 

20 This message is delivered to the proxy server 88 which in turn passes the 
message to the wide area network 18. From the wide area network the 
message proceeds to the foreign server corresponding to the customer's URL 
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address. For purposes of this example the foreign server corresponds to server 
96 which is connected to the Internet. 

In the preferred embodiment of the invention proxy server 88 includes 
screening software graphically indicated 107. Screening software is preferably 
operable to check addresses to which messages are being directed by the ATM 
and to selectively prevent the sending of messages to particular addresses. 
This serves as a "fire wall" and is desirable for purposes of preventing fraud in 
the system. 

As shown in Figure 20, the foreign server 96 is preferably operable to 
communicate HTTP messages, including HTML documents, to the ATM 12 
back through the wide area network 18. This may be done using a secure 
socket connection ("SSC") so as to minimize the risk of interception of the 
messages. Of course other techniques, including encryption message 
techniques may be used to minimize the risk of interception of the messages. 

As schematically represented in Figure 20 the response document from 
foreign server 96 preferably includes embedded JAVA script is representative 
of or corresponds to a digital signature which identifies the foreign server 96. 
This may be accomplished by loading an HTTP record including a signed 
applet, as previously discussed. An applet in application portion 84 in the 
ATM preferably operates to verify the digital signature in the manner 
described in the prior example, and sends a message indicating that the 
transaction has been authorized. The digital identity of the foreign institution 
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will be stored in memory in the ATM and eventually recorded in the back 
office 94. 

It should be noted that the HTML documents fronvthe foreign server 
96 produce the visual pages or screens of the foreign institution which the 
foreign customer is accustomed to seeing. These pages may correspond to the 
foreign user's "home page' 1 which are tailored specifically to the needs of the 
particular user. 

Figure 21 shows an example of a document accessed through the 
foreign server 96 to the ATM 12. The document from the foreign server may 
include embedded JAVA script which enables operation of the JAVA applets 
in the manner previously discussed to operate the devices 36 in the ATM. As 
shown in Figure 21 the TCP/IP messages to the devices from the JAVA 
applets pass from the device application portion 84 to the device server 92, 
and the instructions therefrom to the device interfacing software portion 64 in 
the ATM. Device operation messages take a reverse path. As these messages 
pass through the device server 92, monitor software 102 monitors them to 
minimize the risk of fraud or abuse. 

As indicated in Figure 21 , the documents from the foreign server 96 
may be operative to display at the touch screen 30 a request for the customer 
to input their PIN. The embedded JAVA script instructions would, as in the 
sample transaction previously discussed, include instructions that enable the 
keyboard 40 to accept «the customers PIN. As in the prior example, a 
transaction record 104 which includes a shared data object concerning this 
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transaction would be opened by the device application software portion. As 
previously discussed, provisions may be made to prevent the passage of PIN 
data through the browser if desired. 

Figure 22 indicates the return of the device operation message and PIN 
5 data to the JAVA applet, which in turn transmits the data back to the foreign 

server 96 through the wide area network 1 8 using the secure socket 
connection. From this point the transaction proceeds generally as previously 
described, except that the foreign server 96 sends the HTTP records, including 
HTML documents, and receives the messages from the document handling 

1 0 portion of the ATM. The foreign server 96 includes the JAVA application 
software necessary to include the embedded JAVA script in the documents 
that are sent to the ATM to operate the devices 36 in the machine. 

As the foreign server 96 operates the machine, the monitor software 
102 in the device server 92 is operative to monitor the messages in the manner 

15 previously discussed. Such monitoring would for example, operate to prevent 
the dispense of unduly large amounts of currency out of the machine. The 
monitoring software may also operate to restrict certain foreign institutions to 
a subset of the transaction machine devices or capabilities. This is done based 
on data stored in memory which limits the devices or activities that can be 

20 carried out from documents at certain addresses. This may be achieved for 
example through the use of code plug-ins which implement a class of the 
transaction objects which limits the operations that can be performed. For 
example, the operations which enable connection to the foreign server may 
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instantiate the objects which provide specified limited capabilities for 
messages received from the foreign server. This may for example limit the 
amount of money dispensed, prevent operation of a check acceptance device, 
limit the dispense to printed documents such as tickets, prevent operation of 
5 the cash dispenser or limit use of the machine in other appropriate ways. This 
may be done based on the addresses or portions of addresses for documents. 

If the capabilities of the machine to the foreign customer are limited, 
the foreign customer may be provided with a visual interface from the foreign 
bank based on the transactions the machine can perform and that the owner of 

10 the machine will allow. As a result the documents accessed at the foreign 
bank server may be a variation of what the customer would be provided at a 
machine operated by the foreign bank. This could be based on documents 
specifically developed for operating foreign machines, or could be a variant of 
the usual foreign bank interface with visual indications that certain 

15 transactions are not available. In some instances the interface may indicate 
that some transactions are available with an associated service charge. 

The ATM of the described embodiment may enhance security by 
limiting the addresses that the browser may access. This may be done by 
maintaining a list in the memory of the machine. This list may be maintained 

20 in HTTP record(s) (including documents) accessible through the home bank's 
intranet. The machine may access the record periodically and update the 
memory data. This record may itself require a digital signature corresponding 
to a signature in the terminal memory before the data will be loaded into 
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terminal memory. This information may also include the instructions and 
information for the ATM to verify that the messages it receives by accessing 
documents on the foreign server are genuine. This may include digital 
signatures which when transferred using public key or private key encryption 

5 techniques verify the messages as genuine. The machine checks to be sure the 

signature in the records accessed from the foreign server corresponds to the 
digital signature for that address stored in memory, and enables operation of 
transaction devices, such as the cash dispenser, only when such 
correspondence is present. Of course various approaches to verifying and 

10 encrypting messages may be used in various embodiments. As used herein 
signatures or signed record encompass any indicia which is included in or is 
derivable from a record which is indicative that it is authorized. 

As can also be appreciated from the foregoing disclosure, the foreign 
server 96 may communicate to the user through the touch screen in a language 

1 5 that is different from that normally used by the customers of the institution 

that operates the computer system 14. As a result the HTML documents may 
display requests to dispense currency of a type or in an amount which is not 
included in the ATM. To accommodate this situation an applet is preferably 
included in the device application portion 84 to deal with requests for foreign 

20 currency. The foreign currency applet causes the ATM to send a message 
back to its home server for purposes of calculating a closest amount which 
may be provided to the customer in the available currency in the ATM which 
corresponds to what the customer requested. As will be appreciated, this 
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applet will he operative to call the particular function address within the home 
server 90 that is capable of providing this function. When the dispense is 
made the applet is also operative to indicate to server 96 that the amount 
dispensed differs somewhat from the amount the customer requested. Of 
S course in other embodiments, other approaches may he used. Alternatively an 
applet in the machine may generate visual displays that show equivalents in 
local currency when foreign currency amounts are displayed or processed. 
This may include presenting both amounts on visual displays presented to a 
user. 

10 As represented in Figure 23, when the foreign customer has completed 

their transactions as indicated through the touch screen 30, the foreign server 
96 is operative to send the "go home" message back to the ATM. The receipt 
of this message is operative in the manner previously described to cause the 
device application portion 84 to operate responsive to the embedded JAVA 

1 5 script instructions to configure the HTML document handling portion to cause 

the browser 76 to reestablish communication with the home server 90, or other 
designated document address. 

As indicated in Figure 24 the applet in the device application portion 
84 which processes the "go home" message is preferably operative to 

20 reconnect to the home server 90 as well as to send the transaction record 
information in record 104. This transaction record information which is 
preferably packaged in a data object, includes the customer name, the foreign 
institution name, digital identifier, amount information concerning amounts 
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dispensed, transferred or deposited, and all other pertinent transaction data. 
The transaction data is used by applets in performing transaction steps in 
which any portion of the data is required. At the completion ofthe customer's 
activity at the machine an applet provides a transaction data message which 

5 includes at least a portion ofthe collected data. This data is communicated 

from server 90 through the CGI 106 to the home hank's back office 94. This 
information is stored in the back office for later use for purposes of settlement 
with the foreign bank operating the foreign server 96. Alternatively or in 
addition, transaction data may be recorded in the terminal in memory as well 

10 as in hard copy on a journal printer. Transaction data may be stored for 
downloading in a batch or by passing objects including data from many 
transactions. Batch data may be communicated at times and to addresses as 
may be stored in memory in the terminal configuration data. 

An advantage of embodiments of the invention is that transaction data 

1 5 may be delivered to addresses in a local area network or in a wide area 

network such as the Internet. This facilitates conducting wide varieties of 
transactions and enables directing messages related to tracking use (such as for 
electronic purse type smart cards) or for settlement of various transaction types 
to a selected system address. 

20 It will be appreciated that the described embodiment of the automated 

banking machine and system of the present invention provides the advantage 
that when the machine is connected to a wide area network such as the 
Internet, customers are able to carry out their banking transactions virtually 
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anywhere in the world. Further, despite the broad capabilities of the system, 
because the machine may be monitored locally, both in terms ofconnection 
and activity, the risk of fraud is minimized. 

Embodiments of the invention may include a further feature to 
5 facilitate access to documents in the network to which the machine is 

connected. This feature is operative to determine if an HTTP record such as 
an HTML document or other item is accessible at an address for downloading 
before the computer will attempt to access the record. This avoids transaction 
time outs that might otherwise occur as a result of inability to access a record 

10 due to the server through which the record is normally accessed being down. 
Other embodiments may consider both the size of the record and the transfer 
rate and determine that a transfer speed for the record is not sufficiently rapid, 
so that an alternative record should be transferred. 

In one embodiment this feature is achieved through use of a separate 

1 5 program or applet which checks to see if a server that the computer will 
subsequently want to access is alive. The applet operates responsive to 
receiving an address or portion thereof, to which a connection will be made. 
The applet operates to make a socket connection to the address and loads a 
small but sufficient amount of the record or otherwise operates to determine 

20 that the server through which the record must be accessed is alive. In response 
to the applet verifying the operation of the remote server, or otherwise 
determining that conditions indicative that the record may be accessed or 
loaded, the computer then operates so that the browser or similar software 
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component is enabled to navigate to the address al the appropriate time in the 
transaction sequence. If the applet is unable to detect that the remote server is 
alive, or determines thai it does not appear the record may be successfully 
accessed or loaded, steps may be taken to access alternative addresses or to 
5 discontinue the transaction. Alternative addresses to access may be based on 

data stored in the memory of the terminal or may be obtained by accessing 
documents either locally or remotely which include data from which 
alternative addresses may be obtained or derived. Alternative addresses are 
similarly checked to make a determination that the records can be accessed 

10 before attempts are made to access the alternative records. This approach 
avoids delays in carrying out transactions. 

Alternative embodiments may employ other approaches to determine if 
desired HTTP records such as HTML documents may be successfully 
accessed and/or downloaded adequately before the browser providing the 

1 5 customer interface attempts to access the document. Such embodiments may 
consider in determining whether the document can be successfully accessed, 
the transfer speed or other conditions related to system operation or document 
content. For example, the applet which tests to determine that the HTTP 
record can be accessed, or a further applet, may determine the transfer rate at 

20 which the record can be transferred to the computer. The rate at which the 

data can be transferred may be compared to data stored in memory, and if the 
rate is slower than the data representative of the desired stored rate an 
alternative record is accessed. This may be for example an HTML document 
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stored locally in the machine. Other embodiments may include programs 
which consider the size of the HTTP record and the transfer rate in 
determining a transfer speed. Such programs then determine if the record can 
be transferred fast enough to suit the parameters established in the 
configuration in memory, and if not, alternative addresses are accessed. Such 
alternative records may be similarly tested for transfer speed before being 
transferred. 

Programs may also consider other factors in deciding to access a 
particular address, such factors may include for example day and time 
information, or information from sensors such as sensors in a floor indicating 
that other persons are waiting to use the machine. In this way access to 
documents that have extensive outputs which may tend to prolong transactions 
can be avoided even when records can be loaded at an adequate speed. 

While the described embodiment of the automated banking machine 
and system of the present invention is shown with regard to a particular type 
of machine that is made specifically for connectibility to local or wide area 
networks, conventional automated banking machines may also be adapted to 
include such capability. Specifically the HTML document handling portion 
and device application portions may be included with other conventional 
software which operates within an automated banking machine. This enables 
such ATMs to operate either in the conventional proprietary network or as part 
of a wide area network. In addition, automated banking machines may be 
configured to operate their devices through the device interfacing software 
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portion of the invention or through a different software interface when 
operating in a conventional network. Such machines may switch to requiring 
device messages to be passed through a device server when operating under 
the control of a server within the wide area network to maintain security 

5 within the system. In this way a single ATM could operate in proprietary 

networks in the manner of current ATMs as well as in the network 
configuration of the system of the invention. 

Alternative embodiments of the invention operate to communicate 
transaction messages used in a proprietary ATM network. This may be 

10 accomplished by using a CGI in connection with either the HTML document 
handling portion of the ATM or the HTTP home server or other server. The 
CGI operates in connection with a message conversion program and database 
to cull the necessary data from the HTML documents and response messages 
and generate the defined transaction request messages appropriate for the 

1 5 proprietary transaction network. Likewise, the message conversion program 

and CGI operate to receive function command messages from the proprietary 
network and convert them and generate appropriate HTML documents and/or 
TCP/IP messages for use by the ATM. Because these proprietary network 
formats are defined and the data necessary to produce and interpret the 

20 messages are known, the use of the ATM 1 2 directly in a conventional 
proprietary ATM network is achieved. 

Conventional ATM transaction messages are defined layout messages 
that do not include HTML documents on HTTP messages. An example of 
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known conventional messages used to operate ATMs are Diebold 91 X 
messages. Such messages generally involve transmission of a request 
message from an ATM in a defined layout including customer input data 
(account/pin) and an indication of the type and amount of transaction 
requested. The request message is received by an ATM host computer which 
sends back a response message with a defined layout which includes an 
indication whether the transaction is authorized. The ATM then returns 
another message to the host computer indicating whether the machine was able 
to carry out the transaction. The messages used in such conventional 
proprietary networks generally occupy relatively little band width. 

In connecting the ATM of the invention to such a network, a server is 
provided. The server is in operative connection with a memory which 
includes a relational database which holds the message conversion and 
document creation data. In one configuration, the server is connected to the 
document handling portion through a network, or may reside on the computer 
of the ATM. The server produces the documents which the browser accesses 
and which include the transaction device instructions. The server (or a 
connected server) communicates the conventional messages with the host. 
One server may provide an interface for several ATMs connected to it in a 
LAN, or alternatively, each ATM may have its own server operating therein. 

The ability of ATM 12 to communicate in a proprietary network also 
enables operation of the ATM in a manner in which the interface is generated 
by a user's home institution in the manner previously described, but in which 
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' transactions are authorized through messages directed through a proprietary 
ATM network. This achieves the security of using the proprietary network 
while providing the customer with the advantages of the familiar home bank 
interface and/or "personal home page" interface. 
5 In such a configuration the ATM transaction function devices may be 

operated in a conventional manner in response to conventional ATM 
transaction messages such as Diebold 91X messages, in the proprietary 
network. The customer output devices, such as the screen (and speakers if 
provided) communicate through a browser connected to a local or wide area 
1 0 network. The browser accesses documents to prompt a customer through 

operation of a transaction, but the documents do not include instructions which 
cause operation of devices such as the cash dispenser. 

In one configuration the browser may be operated by the computer in 
response to the status of devices in the machine, as the devices are operated in 
1 5 response to conventional ATM messages. In this manner the browser may be 

navigated to selected addresses, including addresses which are associated with 
the customer based on customer input data. However, as the documents 
received by the browser will not operate the transaction function devices, there 
is less need for security measures in accessing documents. As a result, the 
20 customer may still operate the machine in response to a familiar and unique 

interface, and marketing information such as advertising or other material may 
be presented in the transaction sequence. 
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In other embodiments machines may perform some device functions 
based on conventional messages, while others may be performed in response 
to instructions in HTML documents or other HTTP messages. For example 
HTML documents may provide considerable data for use by printers or other 
5 output devices. Some embodiments may access documents with instructions, 
but may ignore some and act in response to others. The approach may be 
selected by the systems operator by configuring the software based on their 
requirements. 

A further advantage of the system configuration of one preferred 
1 0 embodiment is that it has enhanced flexibility for communicating messages 
associated with the ATM. The device manager 68 preferably generates status 
messages associated with the status of devices 36. These status messages may 
commonly represent information about conditions which exist at the devices. 
Such messages may indicate that supplies of paper for printers or currency, are 
1 5 low or are depleted. Other messages may indicate that devices are not 

functioning properly. Often such messages indicate that the ATM requires 
servicing. All such types of messages are referred to herein interchangeably as 
status or fault messages. 

The device interfacing software portion 64 communicates through the 
20 intranet 16 using TCP/IP messages. While the messages associated with 
transactions previously described are directed to the device server 92, the 
software portion 64 may include a server and be configured to address fault 
and status messages to other addresses in the intranet or the Internet. For 
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example, such fault or status messages may be directed to a software 
application which delivers messages to a service provider. Further, fault 
messages may be selectively directed based on the nature of the fault 
indicated. For example, fault messages indicative of a need to replenish 
5 currency or supplies may be directed to an address in the intranet associated 

with an entity who has responsibility for replenishing supplies. Alternatively, 
fault messages which indicate a need for other types of servicing may be 
directed to an address associated with an entity who can provide the type of 
servicing required. 

1 0 Alternatively, the selective dispatching of fault messages to addresses 

in the intranet 16 may be accomplished by appropriately configuring device 
server 92. In addition, either software portion 64 or device server 92 may 
direct fault messages from the ATMs to a fault handling system such as to a 
computer operating Event Management System™ software available from 

15 Diebold, Incorporated. Such software is operative to resolve the nature of the 

fault condition and to notify appropriate personnel of the corrective action to 
be taken. 

The ATM 12 may further include a software function to assist in 
diagnosing problems and providing remedial service. As graphically 
20 represented in Figure 2, alternative embodiments of the ATM 12 may include 
a mini-HTTP server 109 which is in communication with the device 
interfacing software portion 64. Server 109 is configured to receive device 
status messages and to produce HTTP records including HTML documents in 
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response thereto, which provide data representative of device status to a 
diagnostic device 110 such as a hand held computer terminal. Server 109 
includes a CGI for interfacing with the device software so that a technician 
may access the information in the records accessible at the HTTP addresses 
related to status messages and input test and corrective instructions through 
diagnostic device 110. The HTTP records and/or HTML documents generated 
by server 109 may preferably include graphic and audio instructions indicative 
of conditions such as problems, as well as corrective action data and repair 
instructions. 

In alternative versions of the invention the functions of the mini-HTTP 
server 109 may reside in device server 92. This may be particularly 
appropriate where the function of the device server resides on the computer in 
the ATM. Regardless of where the function resides the use of the visual and 
audio components of HTML documents associated with maintenance and 
diagnostic messages facilitates servicing of the ATM. 

These records delivered through the mini-HTTP server include 
instructions that correspond to the status or fault conditions. Such records or 
documents may be accessed locally as previously discussed, or remotely. A 
technician using a hand held computer which includes a browser or other 
software operative to access the HTTP records may access the documents 
locally for purposes of maintenance, diagnosis and servicing. In some 
situations the customer interface and browser associated therewith may be 
used to access the mini-HTTP server, or a separate browser, display and input 
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devices on the machine and intended for use servicing activity may be used. 
Alternatively, the fault and status messages may be monitored from terminals 
at locations anywhere that are connected in the network. The mini-HTTP 
server handling status and fault messages may also be configured to send an e- 
mail or similar message to a selected address whenever a particular condition 
or group of conditions exist. 

A further advantage of this feature is that HTTP messages may also be 
sent to the mini-HTTP server to attempt to correct problems. Such messages 
may include running diagnostic tests and receiving results. It may also include 
operating devices to test or attempt to clear jams and other malfunctions. This 
can often be done from remote locations. Of course, when there is a 
significant risk of unauthorized access to the server handling default or device 
messages, appropriate security measures should be taken. 

The HTTP records which indicate the status of the transaction function 
devices may have different forms depending on the software configuration and 
the needs of the system operator. In some embodiments the device status 
information for one or more devices may be represented by indicia contained 
within a data object. The data object may be transferred to other connected 
computers to provide the status data. The transfer of the data object may be 
accomplished by remote method invocation (RMI) for example. The data in 
the transferred data object may then be used to generate message and/or 
outputs desired by the system operator. This technique may be particularly 
useful when the operator wishes to connect the machine to an existing 
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monitoring system and indicia included in the data object can be used to 
generate outputs or messages indicative of device status that can be processed 
by the existing system. Plug-ins may further be used to achieve 
communication between existing monitoring systems and transaction 

5 machines which have different types of status conditions or different types of 

message formats. This includes machines which have different types of 
transaction function devices and capabilities. 

The technique of transferring a data object may also be used to conduct 
testing or modification of transaction function devices. For example, indicia 

1 0 in the data object may be modified by a servicer and the object passed back to 

the machine. The software in the machine may cause the transaction function 
devices to operate or change conditions or programming in response to the 
modified data object. This may include for example clearing a fault indication 
or causing a device to operate to clear a jam or to conduct a test. The results 

1 5 of such activity may be reflected in modified indicia in the data object which 

may then be transferred to the computer in the diagnostic terminal. Of course, 
the approaches discussed herein are exemplary and other approaches will 
become apparent to those skilled in the art from the description herein. 

Figure 25 shows a schematic view of a network configuration for an 

20 alternative embodiment of the automated banking machine of the present 
invention. The embodiment shown in Figure 25 includes an automated 
banking machine specifically adapted for operating in connection with 
conventional automated banking machine systems such as systems which 
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operate using Diebold 91 X ATM message formats or other non-HTTP 
conventional format. A host computer 120 is a conventional ATM host which 
communicates using such messages. The host communicates with an interface 
server schematically indicated 122. Interface server 122 operates in the 
5 manner previously discussed and is in operative connection with a memory 

that includes the information necessary to convert HTTP messages that pertain 
to a transaction request to a 91 X request message or other conventional 
message, which can be handled by host computer 120. Likewise interface 
server 122 and the instructions and data stored in memory are operative to 

10 convert a conventional 91 X command message or other conventional 

command message from the host 120 into HTTP messages which can be used 
by the automated banking machine to carry out the command. Similarly 
interface server 122 is operative to receive the HTTP messages which 
correspond to the response of the automated banking machine to the 

1 5 commands and to produce a 91 X response message or other conventional 

response message to the host. In accomplishing these functions the interface 
server communicates with a interface client 124 which in the preferred 
embodiment is a COMM plug in which operates on the banking machine 
terminal under a Windows NT® operating environment. Interface server 122 

20 also includes a command/status gateway 126. The command/status gateway is 
operative to receive command and status messages from the software portions 
handling the functional devices within the machine. The messages concerning 
the devices are used in producing transaction messages to send back to host 
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120. In addition, Ihc command status gateway portion also produces status 
messages indicative of the status of devices which may also be communicated 
to the host. 

The interface server 122, command status gateway portion 126 and 
5 interface client 124 may reside in software on the automated banking machine 

terminal. In this configuration the terminal appears to the host computer to be 
a conventional machine. Alternatively interface server 122 and command 
status gateway portion 126 may reside on a separate server, while the interface 
client portion 124 may reside on the terminal. This enables the interface 

1 0 server 1 22 to handle a number of automated banking machines by connecting 
the machines to the interface server through a network. 

The alternative configuration of the automated banking machine 
system shown in Figure 25 is particularly adapted for use in connection with 
existing ATM system. The machine includes an HTML document handling 

15 portion 128 which includes a browser which operates in the manner of the 

embodiments previously described. The HTML document handling portion is 
alternatively referred to as a browser herein for purposes of simplicity. The 
HTML document handling portion operates in connection with a network 130 
to access HTTP records in the form of HTML documents through servers 132, 

20 1 34 and 136. For purposes of this example server 1 32 will be considered the 

server of the home bank which operates the automated banking machine. The 
browser portion 128 is enabled to access documents of its home bank for 
purposes of obtaining content and instructions for purposes of outputting 
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information to customers as well as for operating devices on the machine. 
Servers 1 34 and 1 36 arc representative of other servers which the automated 
banking machine may be instructed to access for purposes of downloading 
documents which include information or instructions. Often such documents 

5 from non-home bank servers will include information which is to be presented 

to customers such as advertising, promotional material, stock quotations or 
other types of information. It should be understood that the servers 1 34 and 
1 36 may be directly connected to network 1 30 or may be accessed through 
other networks and servers. In some embodiments such servers may be 

1 0 accessed through the Internet for purposes of providing documents to the 
automated banking machine. 

Document handling portion 128 includes a terminal theater software 
portion schematically indicated 138. Terminal theater portion 138 is 
schematically shown in greater detail in Figure 26. Terminal theater portion 

15 138 includes a back stage frame 1 40 and a theater frame 1 42. The back stage 

frame 140 although it resides in the browser, is not visible on the screen of the 
automated banking machine. The theater frame 142 is a visible frame and 
controls what is shown to the customer. 

As schematically represented in Figure 25 the HTML document 

20 handling portion also includes a terminal director portion 144. The terminal 

director portion includes directors which are related instances of applets which 
are used in carrying out particular types of transactions. The terminal directors 
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generally correspond to Ihe operation of the JAVA applets in the previously 
described embodiment. 

The automated banking machine of the alternative embodiment further 
includes a transaction services application (TSA) schematically indicated 146. 

5 The transaction services application provides security, terminal condition, 

terminal authorization and key management services within the automated 
banking machine. The transaction services application includes a function for 
communicating HTTP messages with the interface server 122. The transaction 
services application may also communicate through a network such as 

10 network 130 in a manner later explained. The transaction services application 
also provides a server function which enables the transaction services 
application to carry out the functions of the device server 92 in the previously 
described embodiment. 

The automated banking machine of the alternative embodiment further 

15 includes JAVA common device interfaces schematically indicated 148. The 

JAVA common device interfaces in the preferred embodiment are related 
instances of applets which control and coordinate the operation of the 
functional devices 150 of the machines which perform transaction functions. 
The functional devices may include devices of the types described in 

20 connection with the previous embodiment or other types of devices which 
operate to carry out a function related to a transaction. The JAVA common 
device interfaces 148 communicate with the functional devices through 
common device interfaces schematically represented 152. The common 
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device interfaces (CDIs) provide an interface that controls the 
electromechanical modules in the functional devices included in the automated 
hanking machine. The common device interfaces are schematically shown in 
connection with a diagnostic server 154. The diagnostic server operates in a 

5 manner similar to server 109 of the previously described embodiment. The 

diagnostic server 154 is useful in diagnosing status and in correcting problems 
with the devices in the automated banking machine. 

Referring again to Figure 26 the backstage frame 140 within the 
terminal theater portion 138 is a component called the backstage applet 1 56. 

1 0 The backstage applet 1 56 is preferably a relatively thin component. 

Instructions referred to as script included in documents accessed by the 
browser selectively cause the backstage applet to notify a terminal director 
when an action is to take place in response to the instructions included in the 
accessed document. The backstage applet also operates to request that a new 

1 5 HTML document be accessed. The backstage applet also provides access to 
the shared transaction data object previously discussed which holds 
transaction data. 

The theater frame 142 controls the user interface as seen by the user of 
the automated banking machine terminal. Client HTML schematically 
20 represented 158 in the theater frame 142 defines the identifying indicia 

associated with events sent to a director manager through the backstage applet 
and provides an interface to the director manager's public methods. The 
director manager schematically indicated 160 in Figure 26, has a class which 
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resides in the transaction services application (TSA) 146 as shown. The 
director manager class residing in the TSA process is operative to load the 
terminal directors 144 to the I ITML document handling portion. The director 
manager also includes a backstage applet class that resides in the backstage 
5 frame 140. The backstage applet class of the director manager provides an 

interface for the client HTML to make requests on the director manager. 
Instructions in HTML documents can pass events through the backstage applet 
1 56 to the director manager. Such events include a request to authorize a 
transaction. Such requests may also include indications that the customer has 

10 completed a transaction or that a document loaded by the browser includes 

instructions requesting that the session be terminated. Other events which can 
be passed through the director manager include print events. Other events 
which can be passed through the backstage applet to the director manager 
include an indication that an entry was cancelled, or other defined user events. 

1 5 In response to receiving events the director manager of the 

embodiment shown responds to instructions in documents accessed by the 
browser to perform functions which include changing the content of the 
theater frame 142. The director manager responsive to such instructions, also 
changes the active terminal director class. The director manager also caches 

20 terminal director classes for later use or loads terminal director classes and 

HTML documents from a list of available servers. The director manager also 
provides access to the shared transaction data object holding transaction data 
for a particular transaction. The director manager also sends terminal theater 
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evenls to the backstage control class of the current terminal director and 
provides a screen timeout timer. OF course in other embodiments the terminal 
director may carry out other functions. 

In operation of the alternative embodiment shown in Figure 25 the 
terminal directors 144 in the transaction services application 146 enables 
selectively accessing documents with the HTML document handling portion 
128. The documents accessed may include instructions which are used to 
operate the automated banking machine and the functional devices thereon. 
The transaction services application 146 is further operative to communicate 
the HTTP messages which are passed to the interface server 122 and which are 
used to generate conventional ATM messages which can be handled by the 
host 120. The dispensing of currency and other transfers of value are carried 
out in response to approval from the host 120, while the interface and other 
functions are controlled through instructions in documents accessed through 
the browser. 

In one preferred embodiment the ATM or other transaction machine 
communicates with the conventional ATM host by passing the transaction data 
object between the computer in the ATM and the interface server. This 
transfer is preferably accomplished by the remote message invocation (RMI) 
feature of software such as JAVA. Of course other methods for transferring 
the data object file using HTTP may be used. 

As previously discussed, the transaction data object holds transaction 
data. The machine acquires data pertinent to the transaction such as account 
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data from a card, a customer's PIN number, requested transaction(s) and 
amount(s), and includes this data among the transaction data. 

Once the data needed to generate a conventional ATM transaction 
message is represented in the transaction data, the data object is transferred to 

5 the interface server. The interface server is in operative connection willi a 

database 123 or other item holding conversion data as schematically indicated. 
The conversion data is used by the software associated with the server to 
generate a conventional ATM transaction request message to the host 120. 
The conventional message may be formatted as a conventional 91 X message 

1 0 or other conventional non-HTTP transaction message. 

After processing the host 120 responds with a conventional response 
message. The components of the response message are received at the server 
and processed responsive to the conversion data to produce modified 
transaction data in the data object. This modified transaction data preferably 

1 5 includes data indicative of whether the requested transaction is authorized or 

denied, as well as other data. For example, if the transaction is denied it may 
include data which is indicative of the reason for the denial. 

The transaction data object with the modified transaction data is then 
transferred to the computer operating the ATM by RMI or other transfer 

20 method. The transaction services application 146 operating in software 
receives the data object and operates the transaction function devices 
responsive to the modified transaction data. The transaction data object has 
the transaction data therein further modified by the inclusion of information 
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concerning operation of the devices. Alkr Che devices have opcrulcil, the 
transaction data object with the further modified transaction data is passed 
hack to the interlace server 122. The modified transaction data is then used to 
generate a message to the ATM host. The message to the host includes data 

5 corresponding to the modified transaction data. Usually this message is a 

conventional non-HTTP completion message indicating whether the 
transaction was successfully carried out by the transaction function devices. 

The format of the non-HTTP conventional transaction messages may 
be readily changed in the described embodiment. This can be achieved 

10 through the use of plug-ins. The plug-ins are operative to put data into, and to 
extract data from, the transaction data object. The plug-ins achieves 
conversion between the transaction data and desired conventional non-HTTP 
messages. The use of plug-ins enables more readily using the ATM of the 
described embodiment in connection with varied types of conventional 

1 5 transaction networks. 

Transaction data in the transaction data object is also preferably 
operative to have the computer operate the browser to access selected HTML 
documents. This may be done to indicate that the transaction is authorized or 
denied, as well as to access specific documents responsive to components of 

20 the message. For example, customers of banks other than the one operating 

the ATM may be given certain promotions not presented to the bank's existing 
customers. The transaction data indicative of why a transaction is denied can 
be used to access documents which provide an explanation, or can encourage 
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(he customer lo take other action, such us to take a casli advance on a credit 
card or to apply for a loan. 

The system schematically shown in Figure 25 is an example of an 
automated banking machine system that achieves the wide variety of interface 

5 options available through the use ofan HTML interface while preserving 
compatibility with existing banking machine systems and the security 
techniques associated therewith. Of course in other embodiments alternative 
approaches and configurations may be used. 

A further advantage incorporated into the system schematically 

10 represented in Figure 25 is the ability to operate the software components of 
the described embodiment of the present invention in existing automated 
banking machines. As will be appreciated, the handling of HTML documents 
in conventional computers requires inputs through a QWERTY type keyboard 
as well as mouse clicks in locations corresponding to icons or other features 

15 on HTML documents to successfully navigate and use such documents. 

Conventional automated banking machines generally do not include a mouse 
or full keyboard. Rather conventional automated banking machines generally 
include an alphanumeric keypad similar to that used on telephones, as well as 
function keys. Embodiments of the present invention enable the operation of 

20 the system with terminals which have such interfaces operate in a manner 
which attains benefits of the invention. 

Figure 27 shows an example of a conventional automated banking 
machine interface 162. Interface 162 includes an output device which 
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includes a screen 164. Screen 164 may be a CRT, LCD or other conventional 
display screen. In Ihe embodiment shown screen 164 is not a touch screen as 
in the previously described embodiment. A plurality of function keys 166 are 
disposed at locations adjacent to the screen 164. A keypad 168 is also 

5 included in the interface 162. Keypad 168 includes alphanumeric keys as well 

as certain other dedicated keys such as "cancel", "correct" and "ok". Other 
keys on the keypad are generally blank but in some instances may be used. 

In the operation of a conventional automated banking machine, screen 
data which is generated from information stored in the terminal memory 

10 produces defined transaction screens which are presented graphically on the 

screen 164. The screens appear in a sequence in response to the transaction 
function selected by the customer. Conventional screens also generally 
include text or graphics representative of selections that can be made by a 
customer. These text or graphic options generally includes lines or other 

15 indicia which extend to the edges of the screen adjacent to one of the function 

keys 166. A user is enabled to select the options by pressing the function key 
which is pointed to by the selection. Likewise in the operation of the 
automated banking machine a user is enabled to input the alphanumeric 
characters which comprise the PIN number as well as numeric amount 

20 information and other instructions by pressing the keys in the keypad 168. 

In one embodiment of the present invention the software operated in 
the automated banking machine operates to convert standard ATM key inputs 
to operating system events such as a mouse click in a desired location or an 
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input from a QWIiRTY type keyboard. The soHware components which 
enable carrying out this function are shown in l ; igure 28-30. These functions 
include a keypad applet 170. The keypad applet 170 in the described 
embodiment is included among the applets in the terminal directors 144. The 
keypad applet 170 supports a subset ofthe keyboard common device interface 
(CDI) functionality. 

The keypad applel 170 coordinates with a keyboard command server 
which operates in the transaction services application 146. The server in the 
transaction services application communicates with the common device 
interface for the keypad and function keys, schematically indicated 172. The 
key CDI in the preferred embodiment is a JAVA program which is referred to 
as a wrapper for the common device interface associated with the function 
keys and the keypad. 

The software further includes a keyboard mapper program 
schematically indicated 174. The keyboard mapper in the preferred 
embodiment is in connection with a database 176 which stores a plurality of 
map sets. In the preferred embodiment the keyboard mapper is an extension 
of the keyboard class of objects used for operating the keyboard. The 
keyboard mapper operates to store sets of keymaps in the database 176. This 
is accomplished by reading information in a configuration database for the 
ATM to obtain the keymaps that are operated in the particular machine. 
During operation, the keyboard mapper selects one of the keymaps as the 
current set. This is done in response to the keypad applet and is based on 
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instructions in I ITTP records which arc selectively accessed. The keyboard 
mapper may select keymaps responsive to instructions in HTML documents 
' loaded through the browser. The keyboard mapper is also operative to enable 
the keypad and function keys appropriate for the particular mapset selected. 
5 The keyboard mapper is further operative responsive to the selected mapset to 
translate a keypad input signal or a function key input signal into a respective 
keyboard or mouse input signal which is then delivered to the keyboard input 
stream or the mouse input stream of the operating system of the computer in 
which the software operates. 

10 In the preferred embodiment the mapsets are each comprised of hash 

tables. Keymap objects are stored as values in the hash tables such that each 
object includes the values and operations necessary to convert any appropriate 
ATM key event to an operating system input event. 

As can be appreciated in the case of function keys adjacent to the ATM 

1 5 screen it may be desirable to provide a mouse input to the mouse input stream 

that corresponds to a particular coordinate location for the mouse input. This 
is provided by the keyboard mapper using the selected keymap set. The 
various keymap sets enable the different function keys to provide different 
types of inputs to the computer operating system responsive to the HTML 

20 document displayed on the browser. Further the keyboard mapper causes the 
pressing of a selected key to produce an input corresponding to a mouse click 
at a selected x,y coordinate position on the screen. It should be understood 
that either keypad keys or function keys can be used to produce mouse inputs. 
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Likewise function key inputs may he converted lo keyboard inputs. In some 
embodiments however it will be desirable to disable the mouse indicator on 
the screen such that the user does not notice a usual mouse icon. Such 
disabling may include in some embodiments reducing the size of the mouse 
5 icon such that it is so small that it cannot be readily seen by a user of the 

machine. 

During portions of some transactions it may be unnecessary for the 
user to press any keys. In such situations some preferred embodiments of the 
invention operate to disable the keypad keys and/or function keys. Because 

10 resources of the computer are used in polling such keys for inputs, the 

cessation of such polling during appropriate times enables the computer 
resources to be devoted to carrying out other functions. This will increase the 
speed at which other activities may be carried out. This may be accomplished 
in some embodiments by the keypad applet operating to remove the key 

1 5 devices from a poll list. 

Figures 28-30 include schematic depictions of examples of the 
operation of the keyboard mapper and the keypad applet. Figure 29 shows an 
example of an input to the keypad 168. In this example the keypad applet 170 
generally in response to instructions in an HTTP record such as an HTML 

20 document or other events, transmits and enables events to the transaction 

services application 146. In response a mapset is selected from the database 
176 corresponding to the particular map name. The keyboard command server 
is further operative to enable the appropriate keys of the ATM. 
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In this example, in response the customer pressing the "OK" key on 
the keypad the CDI generates an appropriate signal to the transaction services 
application. As will be noted from Figure 27 a "OK" key is referred to by 
convention as the "J" key of the ATM interface. The transaction services 
5 application transmits the signal generated from the pressing of the "J" key by 

the customer to the keyboard mapper 174. In response to receiving the signal, 
the keyboard mapper operates to resolve the object in the mapset 
corresponding to the map name which will convert the function key input 
signal to a keyboard input signal which is recognized by the operating system. 

10 By calling the selected object from the mapset, a keyboard input signal is 
produced and delivered into the keyboard stream of the computer. This is 
represented by keyboard stream 178. In the embodiment shown the keyboard 
stream is an input to the Windows NT® operating system. The keypad applet 
1 70 operates to sense the input through its corresponding key listener. Applet 

15 170 is also operative to receive the event and may operate to display an icon or 

other graphic corresponding to what the customer has input. 

Figure 28 shows operation of the keyboard mapper in situations where 
the transaction services application operates to prevent transmitting the data 
input by the customer to the applet 170. This may be desirable for example, in 

20 situations where the input by the customer is the customer's PIN or other data 
which is not to be displayed. In these circumstances the transaction services 
application 146 operates to hold the data input by the customer and to send 
only a signal representative of a holding character, in this case a "*" symbol 
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back to the browser. This is done selectively in response to the instructions 
contained in documents accessed by the browser or in other HTTP records 
accessed by the computer which indicates that the input by the customer 
corresponds to their PIN or other data which is not to be sent to the browser. 

5 In the example shown in Figure 28 only the holding character is passed 

through the keyboard mapper to the browser. In situations where the HTTP 
record accessed invokes methods in which numerical values are to be sent to 
the browser and/or displayed on the screen (such as the amount of a 
withdrawal transaction) the signal sent by the transaction services application 

1 0 to the browser is indicative of the numerical value associated with the key 

pressed. 

Figure 30 is a further example of the operation of the keyboard mapper 
in this case the input corresponds to a function key 166. In this case the input 
is caused by pressing the function key "A" which is shown adjacent to the 

1 5 upper right hand corner of the screen as shown in Figure 27. The signal 

generated in response to pressing the function key is passed to the keyboard 
mapper which in response to the data obtained from the data store 1 76 outputs 
a mouse input corresponding to a mouse click. The mouse input includes data 
representative of the x and y coordinates on the screen where the mouse click 

20 is to be provided. This mouse input signal is passed to the mouse stream input 

schematically represented 180. 

As will be appreciated to enable the automated banking machine which 
processes HTML documents to operate using a conventional ATM interface 
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the mouse input will generally include coordinate locations which correspond 
to a location on the screen adjacent to the particular function key. This is 
because the icon, line, text or other indicia which the customer is selecting by 
pressing the key will preferably appear or extend on the screen adjacent to the 
key. In this way the customer is aware through the visual presentation what 
key to press to make a corresponding selection. A number of function keys 
adjacent to the screen may be operative at any one time. The customer may 
make selections by pressing a function key at one location and then a function 
key at another location disposed from the first location. This will result in 
signals being sent to the mouse stream corresponding to mouse clicks at 
coordinates on the screen adjacent to the function buttons pressed by the 
customer. During transactions various combinations of function and keypad 
keys may be operative and mapped to various keyboard and mouse inputs as 
determined by the selected mapsets. In addition developers may develop 
special mapsets corresponding to the particular graphics in HTML documents 
which are displayed. 

In the foregoing manner keypad inputs to a conventional ATM or other 
automated banking machine keypad can be translated into conventional 
keyboard or mouse inputs which can be identified and processed in a 
conventional keyboard input stream or mouse input stream to a computer. 
Likewise function keys may be translated into mouse inputs at selected 
locations and delivered into the mouse input stream for processing by the 
computer or may be converted into keyboard inputs and delivered to the 
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keyboard input stream. A further advantage of the described terminal 
configuration is that keys may be selectively disabled except when they are 
needed. This may reduce instances of attempts to improperly access the 
machine by pressing keys on the keyboard. Further as previously discussed 
steps may also be taken to disable keys when they are not needed to increase 
transaction processing speeds. 

A further advantage of embodiments of the present invention is the 
ability of the automated banking machine to provide printed documents based 
on instructions in HTML documents. Such printed items may include tickets, 
travelers checks, money orders, bank checks, scrip or other types of 
documents. The ability of preferred embodiments to access and process 
HTML documents enables the printing of graphics and other indicia which can 
produce printed documents having selected appearance features and selected 
ornamental designs. This can reduce the need to utilize preprinted forms and 
also enables the printing of a greater variety of printed formats. Further the 
configuration of some embodiments of the machine enable printing only 
selected portions of transaction information for record keeping purposes 
within the machine while providing versions including enhanced graphics or 
other attractive features to customers. 

Figure 31 is a schematic representation of the operation of the system 
in printing forms using a printer in an automated transaction machine. The 
preferred form of the invention uses the WIN32 printer services which operate 
under Windows NT® 4.0. In the exemplary transaction shown, the director 
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manager class 180 operating in the terminal theater portion 138 initiates a print 
receipt transaction by requesting a printer director 182 to print a receipt. The 
printer director in one preferred embodiment is a collection of instances of 
related JAVA beans which operate to carry out printing activities, and is one 
of the directors among the terminal directors 144. The printer director 
includes a print class which is schematically shown separately which is 
operative to invoke a print URL method. The printer class in the preferred 
embodiment includes access to the shared transaction data object which 
includes the customer specific information concerning the transaction that 
includes indicia representative of information to be printed. In the case of an 
automated banking machine this may include for example indicia 
representative information which is read from a customer's card input to the 
machine and read by a card reader. This would include for example the 
customer's name and account number. The other transaction information may 
include the types of transactions conducted such as a deposit, withdrawal or 
inquiry as well as the amount involved in each respective transaction. 

The transaction services application 146 receives the print request and 
passes the URL string to the WIN printer object 1 84 by the print URL method. 
The URL address in one preferred embodiment is the address of an HTTP 
record such as an HTML document that will be used to format the document 
to be printed, in this case a receipt. This HTML document contains the 
embedded JAVA script that processes transaction data from the transaction 
data object. The URL address of the document may be on a local machine or 
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may be retrieved from another server such as through a network schematically 
indicated 186. Network 186 may be a local area network or a wide area 
network depending on the configuration of the machine. 

The WIN printer object 1 84 next navigates to the address of the 
document to be accessed. This is done in the preferred embodiment using 
Microsoft's C Web Browser2 ActiveX control. When the HTML document 
has been loaded the ActiveX control automatically begins processing the 
content of the accessed document. The transaction services application 146 
invokes the print URL method of the WIN printer object 1 84. The WIN 
printer object uses the ActiveX control to print the current HTML document. 
This printing is processed by the Windows NT<8> print spool and graphics 
components. 

The JAVA CDI receives an event from the print monitor component 
192 that indicates the completion of print spooling. This indicates that a file is 
now available to be read and sent to the common device interface (CDI) 188 
of the receipt printer. 

Next a printer object 190 invokes a read data function in the print 
monitor 192 to determine the location and size of the print data file. The print 
object 190 sends the data or the path name of the data file to the printer CDI 
1 88. The printer CDI 188 then passes the print data to the printer hardware. 
This results in printing of the document. 

Once the receipt is printed the applet from the printer director 182 
issues a request to deliver the printed receipt. The delivery request is passed 
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through the transaction services application 146 to the printer object 190. The 
printer object 190 invokes the deliver method on the printer CDI 188 to cause 
the receipt to be delivered to the user of the machine. The operation of the 
software components enables selectively accessing document formats as well 

5 as using instructions contained in the documents to include transaction data 

within the printed documents. This enables producing documents of varied 
types. In addition it enables providing printing different types of documents 
for different customers. This may be desirable when providing marketing 
information, coupons or similar indicia on transaction receipts. This approach 

1 0 further simplifies providing printed formats in various languages by 

developing HTML documents which provide printed forms in different 
languages. In addition the methods of the present invention may be used for 
providing marketing to customers by profile or types of customer categories, 
as well as on a segment of one basis. 

1 5 While the printing method previously described is discussed in 

connection with delivering transaction receipts, similar methods may be 
invoked for the printing of statements for customers as well as for printing a 
transaction journal within the automated banking machine. Further by 
accessing selected documents controlling the format of printing the 

20 information journal records may be provided with consolidated information in 
a manner which enables conserving journal paper within the machine by not 
printing promotional or other types of information that is provided on 
customer documents. 
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The printing method of the present invention also enables printing 
various types of optical indicia such as bar code or other types of machine 
readable indicia which can be used for printing coupons, checks or similar 
articles. Such coding may facilitate tracking the use of such items by 
5 customers for purposes of evaluating the effectiveness of various marketing 
efforts. In addition machine readable indicia may be used for printing on 
items such as deposit envelopes and/or in transaction journals. Such printing 
may facilitate reading such items by machine to verify the contents of 
deposits. 

10 The printing capabilities achieved through the methods of the present 

invention also enables the printing of selected graphical materials. This may 
include for example materials which include imbedded digital signatures 
which can be used to verify the genuineness of the items printed. This may be 
particularly useful for example in situations where the transaction machine is 

1 5 used to print scrip, travelers checks, betting slips or other items having 

independent value. In addition printed documents in full color may be 
produced by including a color printer in the transaction machine. 

Computer software used in operating the automated transaction 
machines of the present invention and connected computers may be loaded 

20 from articles of various types into the respective computers. Such computer 
software may be included on and loaded from one or more articles such as 
diskettes or compact disks. Such software may also be included on articles 
such as hard disk drives, tapes or ready only memory devices. Other articles 
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which include data representative of the instructions for operating computers 
in the manner described herein are suitable for use in achieving operation of 
transaction machines and systems in accordance with embodiments of the 
present invention. 

The exemplary embodiments of the automated banking machines and 
systems described herein have been described with reference to particular 
software components and features. Other embodiments of the invention may 
include other or different software components which provide similar 
functionality. 

Thus the new automated banking machine and system of the present 
invention achieves the above stated objectives, eliminates difficulties 
encountered in the use of prior devices and systems, solves problems and 
attains the desirable results described herein. 

In the foregoing description certain terms have been used for brevity, 
clarity and understanding. However no unnecessary limitations are to be 
implied therefrom because such terms are for descriptive purposes and are 
intended to be broadly construed. Moreover the descriptions and illustrations 
herein are by way of examples and the invention is not limited to the details 
shown and described. 

In the following claims any feature described as a means for 
performing a function shall be construed as encompassing any means capable 
of performing the recited function and shall not be deemed limited to the 
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particular means shown in the foregoing description or mere equivalents 
thereof. 

Having described the features, discoveries and principles of the 
invention, the manner in which it is constructed and operated and the 
advantages and useful results attained; the new and useful structures, devices, 
elements, arrangements, parts, combinations, systems, equipment, operations, 
methods, processes and relationships are set forth in the appended claims. 
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WHAT IS CLAIMED IS: 

1. A method comprising: 

(a) operating at least one transaction function device of an 
automated transaction machine in response to a transaction message 
received without a browser from a host, wherein the message was sent 
from the host as a non-HTTP transaction message; 

(b) accessing a first HTML document with a browser in the 
machine responsive to operation of the transaction function device; 

(c) controlling an output device of the automated transaction 
machine responsive to first instructions included in the first HTML 
document accessed with the browser; 

(d) operating a second transaction function device of the machine 
responsive to operation of the first transaction function device; 

(e) accessing a second HTML document including second 
instructions with the browser, responsive to operation of the second 
transaction function device; and 

(f) controlling the output device responsive to the instructions 
included in the second HTML document. 

2. A method comprising: 

a) operating a cash dispenser in an automated banking machine 
responsive to receipt of at least one non-HTTP message; 
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b) operating a browser in at least one computer in the automated 
banking machine responsive to operation of the cash dispenser, 
wherein the browser is operative to cause at least one output to 
be provided through a display of the automated banking 
machine. 

The method of claim 2, further comprising: 

c) receiving at least one input through at least one input device on 
the automated banking machine; 

d) operating the browser responsive to the at least one input. 
The method according to claim 3, further comprising: 

e) dispatching at least one non-HTTP message responsive to the at 
least one input. 

The method according to claim 4, further comprising a host, wherein the host 
is operative to generate the non-HTTP message causing operation of the cash 
dispense in step (a), responsive to receipt by the host of the non-HTTP 
message dispatched in step (e). 

The method according to claim 5 wherein the non-HTTP messages in both 
steps (a) and (e) include Diebold 91 X messages. 

The method according to claim 3 wherein step (c) includes reading data from a 
card with a card reader. 
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8. The method according to claim 2 wherein step (b) includes processing a 
document through operation of the browser. 

9. Apparatus comprising: 

an automated transaction machine including a display and currency 
dispenser; 

at least one computer, wherein the display and the currency dispenser 
are in operative connection with the computer, the computer including 
software executable therein, the software including a browser; 

a host system, wherein the host system is operative to communicate 
with the computer, wherein the host system is operative to 
communicate using first messages having a first format, wherein the 
first format is a non-HTTP format, and wherein the computer is 
operative responsive to a first message to operate the currency 
dispenser; 

a server, and at least one first HTML document accessible through the 
server, wherein the first document includes display instructions, 
wherein the browser is operative to communicate with the server using 
second messages, wherein the second messages have a second format 
different than the first format, and wherein the computer is operative 
responsive to a first message to access the first document with the 
browser and to control the display responsive to the first document; 
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wherein the computer is operative responsive to a single message to 
operate the currency dispenser and to access the first document with 
the browser. 

Apparatus comprising: 

an automated banking machine including: 

a display device, 

a note dispenser, 

at least one computer in operative connection with the note dispenser 
and the display device, 

wherein the machine is operative to operate the note dispenser responsive to 
non-HTTP messages received from a remote host and to provide outputs 
through the display device responsive to markup language documents 
processed responsive to operation of the note dispenser. 
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ABSTRACT 



An automated banking machine (12) is operative to conduct 
transactions in response to HTML documents and TCP/IP messages 
exchanged with a local computer system (14) through an intranet (16), as well 

5 as in response to messages exchanged with foreign servers (20, 22, 24, 26, 28, 
96) in a wide area network (18). The banking machine includes a computer 
(34) having an HTML document handling portion (76, 80, 82). The HTML 
document handling portion is operative to communicate through a proxy 
server (88), with a home HTTP server (90) in the intranet or the foreign 

1 0 servers in the wide area network. The computer further includes a device 

application portion (84) which interfaces with the HTML document handling 
portion and dispatches messages to operate devices (36) in the automated 
banking machine. The devices include a sheet dispenser mechanism (42) 
which dispenses currency as well as other transaction devices. The device 

1 5 application portion communicates with a device interfacing software portion 
(64) in the banking machine through a device server (92) in the intranet. The 
device server maintains local control over the devices in the banking machine 
including the sheet dispenser. The banking machine operates to read indicia 
on the user's card corresponding to a system address. The computer is 

20 operative to connect the banking machine to the home or foreign server 
corresponding to the system address, which connected server operates the 
banking machine until the completion of transactions by the user. 
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